[Python-Dev] s/hotshot/lsprof

[Brett Cannon]

On 11/21/05, Armin Rigo <arigo at tunes.org> wrote:
> 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.
>

I am perfectly happy with having lsprof be added with all of this and
point 3 (any chance we can replace profile with a wrapper to lsprof
without much issue?).  As for cleanup, I say Hotshot should stay if we
can get it working properly and document its power features.  If we
can't get it to that state then it should go (maybe not until Python
3.0, but eventually).

> 3. Maintenance group: two core developers.

-Brett