launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Nov 16, 2011 at 2:11 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
> +1 on the goal.
>
> I'm guessing that this is using plain python stack traces, rather than the extended ones that include tal information?  I'd be very pleasantly surprised if the code that includes stack traces were as fast as you quote, particularly given actual tal (-like) debugging content. I don't have the code in front of me, but I think the pertinent code is in lp.services.stacktrace.

I've benched it with the simple code in the stdlibrary. I'm going to
get the basic plumbing in place with that as a first round - I'll make
the function to call configurable so we can iterate to use the tal
enabled (or other ones) in future.

> If, as I suspect, it's not, we can try optimizing it; if that fails, i'd like the ability to switch that codepath on. It can be very helpful to see what a template is actually trying to render, and I'd hate to lose that ability.

Yeah, totally with you. I just don't want to bite off more than I can
chew in the first round - no backtrace << a plain back trace <<
enhance backtrace.

If you wanted to see how fast/slow things are, my timing module should
be easily adaptable to the TAL stuff - just need to a) call the right
function and b) include some reasonable proxy data in the stack frames
for it to chew on.

-Rob