[Python-Dev] s/hotshot/lsprof

[Floris Bruynooghe]

Hello

On Mon, Nov 21, 2005 at 12:14:30PM +0100, Armin Rigo wrote:
> On Sun, Nov 20, 2005 at 08:55:49PM -0500, Tim Peters wrote:
> > We should note that hotshot didn't intend to reduce total time
> > overhead.  What it's aiming at here is to be less disruptive (than
> > profile.py) to the code being profiled _while_ that code is running. 
> 
> > hotshot tries to stick with tiny little C functions that pack away a
> > tiny amount of data each time, and avoid memory alloc/dealloc, to try
> > to minimize this disruption.  It looked like it was making real
> > progress on this at one time ;-)
> 
> I see the point.  I suppose that we can discuss if hotshot is really
> nicer on the D cache, as it produces a constant stream of data, whereas
> classical profilers like lsprof would in the common case only update a
> few counters in existing data structures.  I can tweak lsprof a bit
> more, though -- there is a malloc on each call, but it could be avoided.
> 
> Still, people generally agree that profile.py, while taking a longer
> time overall, gives more meaningful results than hotshot.

When I looked into this at the beginning of the summer I could find
none around on the net.  And since hotshot had been around a lot
longer then the new lsprof I just made a conservative choice.

> Now Brett's
> student, Floris, extended hotshot to allow custom timers.  This is
> essential, because it enables testing.  The timing parts of hotshot were
> not tested previously.

Don't be too enthousiastic here.  My aim was to replicate the profile
module and thus I needed to hack this into hotshot.  However I feel
like it is not entirely in hotshot's ideals to do this.  The problem
is that the call to the timing function is accounted to the code that
is being profiled afaik.  Since a generic timer interface was needed
this means that the call goes out from the C code back to Python and
back to whatever-the-timing-function-is-writtin-in.  Thus wrongly
accounting even more time to the profiled code (not sure how long
execing a python statement takes from a C module).  Just keep this in
mind.

> Given the high correlation between untestedness and brokenness, you bet
> that Floris' adapted test_profile for hotshot gives wrong numbers.  (My
> guess is that Floris overlooked that test_profile was an output test, so
> he didn't compare the resulting numbers with the expected ones.)

Iirc I did compare the output of test_profile between profile and my
wrapper.  This was one of my checks to make sure it was wrapped
correctly.  So could you tell me how they are different?

On a stdlib note, one recommended and good working profiler would
definitely be better then two or three all with their own quirks.


Greetings
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org