Re: [Python-Dev] s/hotshot/lsprof
Hi Brett, hi Floris, On Sat, Nov 19, 2005 at 04:12:28PM -0800, Brett Cannon wrote: Just for everyone's FYI while we are talking about profilers, Floris Bruynooghe (who I am cc'ing on this so he can contribute to the conversation), for Google's Summer of Code, wrote a replacement for 'profile' that uses Hotshot directly. Thanks to his direct use of Hotshot and rewrite of pstats it loads Hotshot data 30% faster and also alleviates keeping 'profile' around and its slightly questionable license. Thanks for the note! 30% faster than an incredibly long time is still quite long, but that's an improvment, I suppose. However, this code is not ready yet. For example the new loader gives wrong results in the presence of recursive function calls. 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
Re: [Python-Dev] s/hotshot/lsprof
On Mon, 2005-11-21 at 12:14 +0100, Armin Rigo wrote: Still, people generally agree that profile.py, while taking a longer time overall, gives more meaningful results than hotshot. 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. hotshot used to produce incorrect data because it couldn't track exits from functions due to exception propagation. We fixed that a while back and since then it's been pretty useful for us. While I'm not sure I like the idea of three profilers in the stdlib, I think in this case (unless they're incompatible) it would make sense to keep hotshot around, at least until any new profiler proves it's better over a couple of releases. -Barry signature.asc Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Hi Barry, On Mon, Nov 21, 2005 at 11:40:37AM -0500, Barry Warsaw wrote: Hi Armin. Actually it was SF #900092 that I was referring to. Ah, we're talking about different things then. The patch in SF #900092 is not related to hotshot, it's just ceval.c not producing enough events to allow a precise timing of exceptions. (Now that ceval.c is fixed, we could remove a few hacks from profile.py, BTW.) I am referring to a specific bug of hotshot which entirely drops some genuine time intervals, all the time. It's untested code! A minimal test like Floris' test_profile shows it clearly. 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
Re: [Python-Dev] s/hotshot/lsprof
On 11/21/05, Jeremy Hylton [EMAIL PROTECTED] wrote: Here's another attempt to disentagle some issues: - Should lsprof be added to the standard distribution? - Should hotshot be removed from the standard distribution? These two aren't at all related, unless you believe that two is the maximum number of profiles allowed per Python distribution. They aren't related if Hotshot provides some functionality that lsprof cannot provide (such as profiling C code; I thought Nick Bastin added support for this?). But if there isn't, then there is some soft relatedness between them since it means that if lsprof is added then hotshot could be removed without backwards-compatibilty issues. They are not mutually exclusive, but one being true does influence the other. And as for how many profilers to have, I personally think one is plenty if they all provide similar type of output using similar techniques. But backwards-compatibility obviously is going to make total removal of a module and its API hard so I am thinking more towards Python 3000 and having the best solution in now. Otherwise we should do what must be done to fix hotshot and stick with it. -Brett ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Hi Floris, On Mon, Nov 21, 2005 at 04:41:04PM +, Floris Bruynooghe wrote: 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. Testing is done by feeding the profiler something that is not a real timer function, but gives easy to predict answers. Then we check that the profiler accounted all this pseudo-time to the correct functions in the correct way. This is one of the few way to reliably test a profiler, that's why it is essential. 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? test_profile works as I explained above. Running it with hotshot shows different numbers, which means that there is a bug (and not just some difference in real speed). More precisely, a specific number of the pseudo-clock-ticks are dropped for no reason other than a bug, and doesn't show up in the final results at all. 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
Re: [Python-Dev] s/hotshot/lsprof
Hi Floris, On Mon, Nov 21, 2005 at 04:45:03PM +, Floris Bruynooghe wrote: Afaik I did test recursive calls etc. It seems to show up in any test case I try, e.g. import hprofile def wait(m): if m 0: wait(m-1) def f(n): wait(n) if n 1: return n*f(n-1) else: return 1 hprofile.run(f(500), 'dump-hprof') The problem is in the cumulative time column, which (on this machine) says 163 seconds for both f() and wait(). The whole program finishes in 1 second... The same log file loaded with hotshot.stats doesn't have this problem. 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
Re: [Python-Dev] s/hotshot/lsprof
Armin Rigo 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. I doubt people often find the motivation to dig into this large orphaned piece of software. As Fredrik says: this sounds like the CADT model. The code isn't really orphaned - it's just that it isn't used much. Contributions to this code certainly would still be accepted (and happily so). So essentially: fixing bugs isn't fun, but rewriting it from scratch is. I'm not even sure in this case why we are arguing That's pretty obvious to me: because some people are shy of letting version 0.8 of the old software be replaced with version 0.8 of the new software, which is then replaced with version 0.8 of the next rewrite. Instead, we should stick to what we have, and improve it. 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. I'm not certain lsprof has properties 2 and 3; property 1, so far, is only asserted by the library author himself. Perhaps it is true what Fredrik Lundh says: there shouldn't be a profiler in the standard library at all. Regards, Martin ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Brett Cannon wrote: But this worry, in my mind, is alleviated since I believe both Michael and Armin are willing to maintain the code. With them both willing to make sure it stays working (which is a pretty damn good commitment since we have two core developers willing to keep this going and not just one) I think this worry is dealt with. So far, neither of them has explicitly said so: Michael said he will be around; and I'm certain that is the case for Python as a whole. An explicit commitment to lsprof maintenance would help (me, atleast). In other words, I say let Armin and Michael add lsprof and the wrappers for it (all while removing any redundant profilers that they have wrappers for) with them knowing we will have a public stoning at PyCon the instant they don't keep it all working. =) I would prefer to see some advance support from lsprof users, confirming that this is really a good thing to have. Regards, Martin ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Jim Jewett wrote: Jeremy Hylton jeremy at alum.mit.edu Should lsprof be added to the standard distribution? Should hotshot be removed from the standard distribution? These two aren't at all related, unless you believe that two is the maximum number of profiles allowed per Python distribution. One is a better number. (There should be one-- and preferably only one --obvious way to do it.) Adding a second (let alone third) module to the stdlib to do the same thing just makes the documentation bulkier, and makes the where do I start problem harder for beginners. And yes, I think beginners are the most important audience here; anyone sufficiently comfortable with python to make an intelligent choice between different code profilers is probably also able to install 3rd-party modules anyway. Chiming in as a user of 'profile', that has also attempted to use hotshot. . . I used profile heavily when we working on the implementation of the decimal module, trying to figure out where the bottlenecks were (e.g., profile showed that converting to integers to do arithmetic and back to sequences to do rounding was a net win, despite the conversion costs in switching back and forth between the two formats). I tried using hotshot to do the same thing (profiled runs of the arithmetic tests took a *long* time), and found the results to be well-nigh useless (I seem to recall it was related to the fact that profile separated out C calls, while hotshot didn't). So my experience of hotshot has been sure it's slightly less invasive, but it doesn't actually work. If hotshot can be replaced with something that actually works as intended, or if lsprof can be added in a way that is more closely coupled with profile (so that there is a clear choice between less invasive but less detailed results and more detailed results but more invasive during execution), I'd be quite happy. If a statistical profiler was later added to round out the minimally invasive end, that actually makes for a decent profiling toolset: 1. Use the statistical profiler to identify potential problem areas 2. Use hotshot/lsprof to further analyse the potential problem areas 3. Use profile to get detailed results on the bottlenecks Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Brett My question is whether anyone is willing to maintain it in the Brett stdlib? My answer is: I'm not sure it matters at this point. There are so many profiling possibilities, it doesn't seem like we yet know which options are the best. There is some tacit crowning of best of breed when a package is added to the standard library, so we probably shouldn't be adding every candidate that comes along until we have a better idea of the best way to do things. Skip ___ 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
Re: [Python-Dev] s/hotshot/lsprof
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
Re: [Python-Dev] s/hotshot/lsprof
On 11/21/05, Armin Rigo [EMAIL PROTECTED] 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 ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Martin v. Löwis [EMAIL PROTECTED] writes: Armin Rigo wrote: If anyone feels like this is a bad idea, please speak up. As stated, it certainly is a bad idea. This is a bit extreme... To make it a good idea, there should also be some commitment to maintain this library for a number of years. So who would be maintaining it, and what are their plans for doing so? Well, the post was made by Armin who has been involved in CPython development for quite a few years now, and mentioned that work on lsprof was done by me who has been around for even longer -- neither of us are going to quit anytime soon. Cheers, mwh -- I think if we have the choice, I'd rather we didn't explicitly put flaws in the reST syntax for the sole purpose of not insulting the almighty.-- /will on the doc-sig ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Michael Hudson wrote: As stated, it certainly is a bad idea. This is a bit extreme... Yes, my apologies :-( To make it a good idea, there should also be some commitment to maintain this library for a number of years. So who would be maintaining it, and what are their plans for doing so? Well, the post was made by Armin who has been involved in CPython development for quite a few years now, and mentioned that work on lsprof was done by me who has been around for even longer -- neither of us are going to quit anytime soon. The same could be said about hotshot, which was originally contributed by Fred Drake, and hacked by Tim Peters, yourself, and others. Yet, now people want to remove it again. I'm really concerned that the same fate will happen to any new profiling library: anybody but the original author will hate it, write his own, and then suggest to replace the existing one. It is the let's build it from scratch attitude which makes me nervous. Perhaps the library could be distributed separately for some time, e.g. as a package in the cheeseshop. When it proves to be mature, I probably would object less. Regards, Martin ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Martin v. Löwis wrote: The same could be said about hotshot, which was originally contributed by Fred Drake, and hacked by Tim Peters, yourself, and others. Yet, now people want to remove it again. I'm really concerned that the same fate will happen to any new profiling library: anybody but the original author will hate it, write his own, and then suggest to replace the existing one. is this some intrinsic property of profilers? if the existing tool has problems, why not improve the tool itself? do we really need CADT- based development in the standard library? (on the other hand, I'm not sure we need a profiler as part of the standard library either, but that's me...) /F ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Fredrik (on the other hand, I'm not sure we need a profiler as part of Fredrik the standard library either, but that's me...) Painful though hotshot can be at times, I occasionally find it extremely useful to zoom in on trouble spots. I haven't used profile in awhile and haven't tried lsprof yet. I would think having something readily available (whether in the standard library or not) would be handy when needed, hopefully with nothing more than python setup.py install required to make it available. Skip ___ 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
Re: [Python-Dev] s/hotshot/lsprof
[Armin Rigo] ... ... 'hotshot', new from 2.2, is quite faster (reportedly, only 30% added overhead). The log file is then loaded and turned into an instance of the same 'pstats.Stats'. This loading takes ages. The reason is that the log file only records events, and loading is done by instantiating a 'profile.Profile' and sending it all the events. In other words, it takes exactly as long as the time it spared in the first place! 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. On modern boxes, any kind of profiling gimmick has the unfortunate side effect of _changing_ the runtime behavior of the code being profiled, at least by polluting I and D caches with droppings from the profiling code itself (or, in the case of profile.py, possibly overwhelming I and top-level D caches -- and distorting non-profiling runtime so badly that, e.g., networked apps may end up taking entirely different code paths). 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 ;-) Moreover, for some reasons, the results given by hotshot seem sometimes quite wrong. (I don't understand why, but I've seen it myself, and it's been reported by various people, e.g. [2].) 'hotshot' doesn't know about C calls, but it can log line events, although this information is lost(!) in the final conversion to a 'pstats.Stats'. Ya, hotshot isn't finished. It had corporate support for its initial development, but lost that, and became an orphan then. That's the eventual fate of most profilers, alas. They're fiddly, difficult, and always wrong in some respect. Because of this, the existence of an eager maintainer without a real life is more important than the code ;-). ___ 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
Re: [Python-Dev] s/hotshot/lsprof
[Martin v. Löwis] I'm really concerned that the same fate will happen to any new profiling library: anybody but the original author will hate it, write his own, and then suggest to replace the existing one. [Fredrik Lundh] is this some intrinsic property of profilers? if the existing tool has problems, why not improve the tool itself? How many regexp engines has Python gone through now? Profilers are even more irritating to write and maintain than those -- and you presumably know why you started over from scratch instead of improving pcre, or whatever-the-heck-it-was that came before that ;-) do we really need CADT-based development in the standard library? Since I didn't know what that meant, Google helpfully told me: Center for Alcohol Drug Treatment Fits, anyway wink. ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Tim Peters wrote: [Martin v. Löwis] I'm really concerned that the same fate will happen to any new profiling library: anybody but the original author will hate it, write his own, and then suggest to replace the existing one. [Fredrik Lundh] is this some intrinsic property of profilers? if the existing tool has problems, why not improve the tool itself? How many regexp engines has Python gone through now? Profilers are even more irritating to write and maintain than those -- and you presumably know why you started over from scratch instead of improving pcre, or whatever-the-heck-it-was that came before that ;-) do we really need CADT-based development in the standard library? Since I didn't know what that meant, Google helpfully told me: Center for Alcohol Drug Treatment I suspect you may already know that Fredrik referred to Cascade of Attention-Deficit Teenagers Where's the BDFL to say yes or no when you need one? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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
Re: [Python-Dev] s/hotshot/lsprof
On Sun, Nov 20, 2005 at 11:33:42PM +0100, Fredrik Lundh wrote: do we really need CADT-based development in the standard library? I didn't recognize the acronym, but Google told me CADT = Cascade of Attention-Deficit Teenagers; see http://www.jwz.org/doc/cadt.html for a rant. --amk ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Tim Peters [EMAIL PROTECTED] 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. A statistical profiler (e.g. http://wingolog.org/archives/2005/10/28/profiling) would be a nice addition, IMHO. I guess we should get the current profilers in shape first though. Neil ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Tim Peters wrote: Center for Alcohol Drug Treatment Besides Jamie Zawinski's definition, Google also told me it stands for Computer Aided Drafting Technology where to draft turns out to have two different meanings :-) Regards, Martin ___ 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
Re: [Python-Dev] s/hotshot/lsprof
On Sat, Nov 19, 2005, Armin Rigo wrote: If anyone feels like this is a bad idea, please speak up. This sounds like a good idea, and your presentation already looks almost like a PEP. How about going ahead and making it a formal PEP, which will make it easier to push through the dev process? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you think it's expensive to hire a professional to do the job, wait until you hire an amateur. --Red Adair ___ 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
Re: [Python-Dev] s/hotshot/lsprof
Armin Rigo wrote: If anyone feels like this is a bad idea, please speak up. As stated, it certainly is a bad idea. To make it a good idea, there should also be some commitment to maintain this library for a number of years. So who would be maintaining it, and what are their plans for doing so? Regards, Martin ___ 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
