[Python-Dev] s/hotshot/lsprof

[Armin Rigo]

Hi Martin,

On Mon, Nov 21, 2005 at 10:29:55PM +0100, "Martin v. L?wis" wrote:
> > I see no incremental way of fixing some of the downsides of hotshot,
> > like its huge log file size and loading time.
> 
> I haven't looked into the details myself, but it appears that some
> google-summer-of-code contributor has found some way of fixing it.

As discussed elsewhere on this thread: this contribution did not fix any
of the mentioned problems.  The goal was only to get rid of profile.py
by linking it to Hotshot.  So the log file size didn't change and the
loading time was only 20-30% better, which is still a really long time.

> So essentially: fixing bugs isn't fun, but rewriting it from scratch is.

Well, sorry for being interested in having fun.  And yes, I am formally
committing myself to maintaining this new piece of software, because
that also looks like fun: it's simple code that does just what you
expect from it.

Note that I may sound too negative about Hotshot.  I see by now that it
is a very powerful piece of code, full of careful design trade-offs and
capabilities.  It can do much more than what the minimalistic
documentation says, e.g. it can or could be used as the basis of a
tracing tool to debug software, to measure test coverage, etc. (with
external tools).  Moreover, it comes with carefully chosen drawbacks --
log file size and loading time -- for advanced reasons.  You won't find
them discussed in the documentation, which makes user experience mostly
negative, but you do find them in Tim's e-mails :-)

So no, I'm not willing to debug and maintain an "unfinished" (quoting
Tim) advanced piece of software doing much more than what common-people-
reading-the-stdlib-docs use it for.  That is not fun.

> Now, it might be that in this specific case, replacing the library
> really is the right thing to do. It would be if:
> 1.it has improvements over the current library already
>    (certified by users other than the authors), AND
> 2.it has no drawbacks over the current library, AND
> 3.there is some clear indication that it will get better maintenance
>    than the previous library.

1. Log file size (could reuse the existing compact profile.py format) --
good "profile-tweak-reprofile" round-trip time for the developer (no
ages spent loading the log) -- ability to interpret the logs in memory,
no need for a file -- collecting children call stats.  Positive early
user experience comes from the authors, me, and at least one other
company (Strakt) that cared enough to push for lsprof on the SF tracker.

There is this widespread user experience that hotshot is nice "but it
doesn't actually appear to work" (as Nick Coghlan put it).  Hotshot is
indeed buggy and has been producing wrong timings all along (up to and
including the current HEAD version) as shown by the test_profile found
in the Summer of Code project mentioned above.  Now we can fix that one,
and see if things get better.  In some sense this fix will discard the
meaning of any previous user experience, so that lsprof has now more of
it than Hotshot...

2. Drawbacks: there are many, as Hotshot has much more capabilities or
potential capabilities than lsprof.  None of them is to be found in the
documentation of Hotshot, though.  There is no drawback for people using
Hotshot only as documented.  Of course we might keep both Hotshot and
lsprof in the stdlib, if this sounds like a problem, but I really think
the stdlib could do with clean-ups more than pile-ups.

3. Maintenance group: two core developers.


A bientot,

Armin.