On Wed, Nov 16, 2011 at 2:11 PM, Gary Poster <gary.pos...@canonical.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
