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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com