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 [email protected] 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 Tim, 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. 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. 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.) Looking at the errors in the numbers pointed us immediately to the bug in the C code. Some time intervals are lost: the ones before an exception is raised or a C function is called or returns. That's a lot of them. The current hotshot is hence not so much a profiler than "a reflection on the meaning of time" (quoting Samuele). > Ya, hotshot isn't finished. It had corporate support for its initial > development, but lost that, and became an orphan then. I will check in the bug fix for hotshot, but the question is what's the point. I would argue that lsprof even with children call stats is much simpler than hotshot. Lines-of-code also reflect that (factor of 2). Obviously hotshot can do much more (undocumented, unmaintained) things beside profiling if you get the correct tools. This plays in favour of lsprof as a stdlib-integrated useful-for-common-people maintained piece of software and hotshot as distributed together with the tools that can use its full potential. A bientot, Armin. ___ Python-Dev mailing list [email protected] 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 08:12:53AM +0100, "Martin v. L?wis" wrote: > If bugs are in the heavily-used parts of the library, like regular > expressions, it doesn't matter much if the original author goes > away for some period of time - other contributors will fix the bugs > that they care about, and not by rewriting the entire thing. I see no incremental way of fixing some of the downsides of hotshot, like its huge log file size and loading time. I doubt people often find the motivation to dig into this large orphaned piece of software. Instead, they rewrite their own profilers, because writing a basic one is not difficult. It is much less difficult than, say, writing a basic regular expression engine (but even the latter has gotten rewritten at times) -- unless you want to go into the advanced corners mentioned by Tim. Some guys posted their 'lsprof' on SF because it was well-polished and they found it useful, so here I am, arguing for a standard library containing preferably simple pieces of code that work and are practical for the common advertised use case. I'm not even sure in this case why we are arguing: the new piece of code's interface can be made 100% compatible with the documented parts of the previous interface; the previous module has been around for longer but so far it produced half-meaningless numbers due to bugs. A bientot, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch Req. # 1351020 & 1351036: PythonD modifications
On Mon, Nov 21, 2005 at 06:08:45PM +1100, Ben Decker wrote: > I think the port has beed supported for three years now. I am not sure what > kind of commitment you are looking for, but the patch and software are > supplied under the same terms of liability and warranty as anything else > under the GPL. Python is not GPL software. If your patch is under the terms of the GPL, it cannot be accepted into Python. Jeff pgpMgSdWqGNaF.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast status, memory leaks, etc
Neal Norwitz wrote: > The big benefit of running with pymalloc is that it only takes about > 1.25 to 1.50 hours to run on my box. When running without pymalloc, I > estimate it takes about 5 times longer. Plus it requires a lot of > extra work since I need to run the tests in batches. I only have 1 GB > of RAM and it takes a lot more than that when running without > pymalloc. sounds like the PSF should buy you some more RAM. ___ Python-Dev mailing list [email protected] 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 09:25:05AM -0500, Barry Warsaw wrote: > hotshot used to produce incorrect data because it couldn't track exits > from functions due to exception propagation. We fixed that a while back It might be me, but I find it a bit odd that you didn't do anything with this fix. I'm sure that for each alternate profiler posted on SF there are ten half-finished ones on somebody's box. The problem of hotshot producing slightly wrong data is not new, and in hindsight the discrepencies only became larger in 2.4 with the introduction of new tracing events (C function calls). At this point I'm interpreting your mail as saying that you don't really mind if hotshot is in the standard library or not, because you are using your own fixed version anyway. Nobody is proposing to wipe out hotshot from the face of the planet. Sorry if I sound offensive, but I'd rather hear the opinion of people that care about the stdlib. Armin ___ Python-Dev mailing list [email protected] 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 16:09 +0100, Armin Rigo wrote: > It might be me, but I find it a bit odd that you didn't do anything with > this fix. Hi Armin. Actually it was SF #900092 that I was referring to. We fixed this bug and those patches were applied to CVS (pre-svn conversion) for both 2.4.2 and 2.5a1. So at least the one I was talking about are already in there! > At this point I'm interpreting your mail as saying that you don't really > mind if hotshot is in the standard library or not, because you are using > your own fixed version anyway. Nobody is proposing to wipe out hotshot > from the face of the planet. Sorry if I sound offensive, but I'd rather > hear the opinion of people that care about the stdlib. I think you just misunderstood me. I definitely care about the stdlib and no, we strongly prefer not to use some locally hacked up Python. E.g. we were running 2.4.1 with this (and a few other patches) until 2.4.2 came out, but now we're pretty much using pristine Python 2.4.2. So I still think hotshot can stay in the stdlib for a few releases, unless it's totally incompatible with lsprof, and then it's worth discussing. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast status, memory leaks, etc
On 11/21/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > sounds like the PSF should buy you some more RAM. I think I still have some allocation from the PSF. Wanna have a party. ;-) Seriously, I don't know that more RAM would help too much. I didn't notice much swapping, but maybe if I had run in bigger chunks --without-pymalloc I would have. I think a bigger bang for the buck would be to buy a Windows box with Purify. Rational was a real pain to deal with, maybe it's better now that IBM bought them. Parasoft (Insure++) was even worse to deal with. There would be many other benefits for someone to do more testing on Windows. The worst part of all this is ... it's still Windows. I'm not tied to Purify, I just don't know anything that works better. I've never used any such tool on Windows though. n ___ Python-Dev mailing list [email protected] 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 08:12:53AM +0100, "Martin v. L?wis" wrote: > > If bugs are in the heavily-used parts of the library, like regular > > expressions, it doesn't matter much if the original author goes > > away for some period of time - other contributors will fix the bugs > > that they care about, and not by rewriting the entire thing. > > I see no incremental way of fixing some of the downsides of hotshot, > like its huge log file size and loading time. I doubt people often find > the motivation to dig into this large orphaned piece of software. > Instead, they rewrite their own profilers, because writing a basic one > is not difficult. It is much less difficult than, say, writing a basic > regular expression engine (but even the latter has gotten rewritten at > times) -- unless you want to go into the advanced corners mentioned by > Tim. > > Some guys posted their 'lsprof' on SF because it was well-polished and > they found it useful, so here I am, arguing for a standard library > containing preferably simple pieces of code that work and are practical > for the common advertised use case. I'm not even sure in this case why > we are arguing: the new piece of code's interface can be made 100% > compatible with the documented parts of the previous interface; the > previous module has been around for longer but so far it produced > half-meaningless numbers due to bugs. > Just because it is starting to feel like the objections are getting spread out amongst various parts of this thread, I want to try to summarize them as I remember them and give my input on them. So one objection seems to be the question of maintenance. Who is going to keep this code updated and running? As has been pointed out, Hotshot is not perfect and its development basically stopped. So people being a little on edge about yet another profiler that might not be maintained seems reasonable. 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. The other issue seems to be some people wanting to keep Hotshot around for a few releases until lsprof can prove its worth. I believe this is what Barry is asking for. Now Armin has said that a wrapper around lsprof can be written that will match Hotshot's public API so its need is not there if lsprof works and the wrapper is good. If it wasn't Armin or someone else whose opinion I trusted, I would say go ahead and keep Hotshot around and then eventually do the wrapper. But since it is Armin making this claim and the PyPy team uses this thing (who has several members who I think know what they are doing =) I have faith in them coming up with a good wrapper. Thus I say removing Hotshot is fine. Lastly, there is the argument of whether we should even include a profiler. Personally I say yes. It is another battery that is rather nice. I think if the profiler finally had a good reputation of being accurate and useful it would get more play in the real world. Plus we already include other development tools such as IDLE with Python so it seems fitting to include other dev tools when we have the code and a maintenance commitment. 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. =) -Brett ___ Python-Dev mailing list [email protected] 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
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. I've never trusted results from hotshot, but I'd rather see it fixed than removed. Jeremy On 11/21/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 11/21/05, Armin Rigo <[EMAIL PROTECTED]> wrote: > > Hi Martin, > > > > On Mon, Nov 21, 2005 at 08:12:53AM +0100, "Martin v. L?wis" wrote: > > > If bugs are in the heavily-used parts of the library, like regular > > > expressions, it doesn't matter much if the original author goes > > > away for some period of time - other contributors will fix the bugs > > > that they care about, and not by rewriting the entire thing. > > > > I see no incremental way of fixing some of the downsides of hotshot, > > like its huge log file size and loading time. I doubt people often find > > the motivation to dig into this large orphaned piece of software. > > Instead, they rewrite their own profilers, because writing a basic one > > is not difficult. It is much less difficult than, say, writing a basic > > regular expression engine (but even the latter has gotten rewritten at > > times) -- unless you want to go into the advanced corners mentioned by > > Tim. > > > > Some guys posted their 'lsprof' on SF because it was well-polished and > > they found it useful, so here I am, arguing for a standard library > > containing preferably simple pieces of code that work and are practical > > for the common advertised use case. I'm not even sure in this case why > > we are arguing: the new piece of code's interface can be made 100% > > compatible with the documented parts of the previous interface; the > > previous module has been around for longer but so far it produced > > half-meaningless numbers due to bugs. > > > > Just because it is starting to feel like the objections are getting > spread out amongst various parts of this thread, I want to try to > summarize them as I remember them and give my input on them. > > So one objection seems to be the question of maintenance. Who is > going to keep this code updated and running? As has been pointed out, > Hotshot is not perfect and its development basically stopped. So > people being a little on edge about yet another profiler that might > not be maintained seems reasonable. > > 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. > > The other issue seems to be some people wanting to keep Hotshot around > for a few releases until lsprof can prove its worth. I believe this > is what Barry is asking for. Now Armin has said that a wrapper around > lsprof can be written that will match Hotshot's public API so its need > is not there if lsprof works and the wrapper is good. > > If it wasn't Armin or someone else whose opinion I trusted, I would > say go ahead and keep Hotshot around and then eventually do the > wrapper. But since it is Armin making this claim and the PyPy team > uses this thing (who has several members who I think know what they > are doing =) I have faith in them coming up with a good wrapper. > Thus I say removing Hotshot is fine. > > Lastly, there is the argument of whether we should even include a > profiler. Personally I say yes. It is another battery that is rather > nice. I think if the profiler finally had a good reputation of being > accurate and useful it would get more play in the real world. Plus we > already include other development tools such as IDLE with Python so it > seems fitting to include other dev tools when we have the code and a > maintenance commitment. > > 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. =) > > -Brett > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] 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
Jeremy> Here's another attempt to disentagle some issues: Jeremy> - Should lsprof be added to the standard distribution? Jeremy> - Should hotshot be removed from the standard distribution? Adding another log to the fire, what about statprof, a sampling profiler, which Neil Schemenauer mentioned? I installed it here at work. Seems to work as advertised. Took me about two minutes to modify our main app to accept a -P command line flag to enable statprof profiling. It has the beauty of being minimally invasive since it only samples the execution state every 100ms or so. Of course, sampling profilers have their own warts, but they avoid some of the problems of instrumenting profilers. Another tack to take would be to modify the generated byte code to only increment counts for each basic block, similar to what gcc's -pg flag does. I think that would yield a fully instrumented profiler, but one that's less invasive than the current alternatives. It could maybe be implemented as an import hook. Of course, such a beast has yet to be written, so this email and a couple bucks will get you a cup of coffee. This entire discussion simply serves to demonstrate that there are lots of different ways to skin this particular cat. How many of these various alternatives belong in the standard library remains to be seen. Skip ___ Python-Dev mailing list [email protected] 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Jeremy> Here's another attempt to disentagle some issues: > Jeremy> - Should lsprof be added to the standard distribution? > Jeremy> - Should hotshot be removed from the standard distribution? > > Adding another log to the fire, what about statprof, a sampling profiler, > which Neil Schemenauer mentioned? I installed it here at work. Seems to > work as advertised. Took me about two minutes to modify our main app to > accept a -P command line flag to enable statprof profiling. It has the > beauty of being minimally invasive since it only samples the execution state > every 100ms or so. Of course, sampling profilers have their own warts, but > they avoid some of the problems of instrumenting profilers. > My question is whether anyone is willing to maintain it in the stdlib? -Brett ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch Req. # 1351020 & 1351036: PythonD modifications
Ben Decker wrote: > I think the port has beed supported for three years now. I am not > sure what kind of commitment you are looking for, but the patch and > software are supplied under the same terms of liability and warranty > as anything else under the GPL. That (licensed under GPL) would be an issue, as we are not accepting GPL-licensed code. I would guess that you are flexibly in licensing, though: we would request that you allow us to relicense the contribution under the terms at http://www.python.org/psf/contrib.html The commitment I was looking for was rather a statement like "I will be maintaining it for several coming years; when I ever stop maintaining it, feel free to remove the code again". So it is not that much past history (although this also matters, and three years of availability is certainly a good record); it is more important to somehow commit to future support, so that we are not left alone with code when cannot maintain if you ever drop out. Regards, Martin ___ Python-Dev mailing list [email protected] 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
[email protected]
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] s/hotshot/lsprof
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.
Note that I have no objection to (and would like to see) a
section in the module documentation saying "This is just
one alternative; many people prefer XXX because of YYY".
This mention would provide enough endorsement for
anyone ready to choose another profiler.
Even putting the alternatives into a single stdlib package
(and making it clear that they are alternatives, rather than
complementary building blocks) is better than simply
leaving them all scattered throughout the stdlib as
roll-the-dice-to-pick alternatives.
-jJ
___
Python-Dev mailing list
[email protected]
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 [email protected] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast status, memory leaks, etc
Neal Norwitz: > I think a bigger bang for the buck would be to buy a Windows box with > Purify. Rational was a real pain to deal with, maybe it's better now > that IBM bought them. Parasoft (Insure++) was even worse to deal > with. My experience with the other Windows option, BoundsChecker, is similarly negative and I haven't bothered upgrading for a couple of versions (so can only use it with VC++ 6). The original developer, NuMega, were great but they were absorbed into Compuware which seems to see it more as a source of consulting income than as a product. I'm fairly experienced with BoundsChecker and related programs (like their profiler) so could run it over a test suite if a license was provided. A demonstration license can probably not be installed on my machine due to earlier installs. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast status, memory leaks, etc
Neal Norwitz wrote: > I think a bigger bang for the buck would be to buy a Windows box with > Purify. Rational was a real pain to deal with, maybe it's better now > that IBM bought them. Parasoft (Insure++) was even worse to deal > with. There would be many other benefits for someone to do more > testing on Windows. I don't think there's a shortage of Windows boxes among the python-dev crowd (I have plenty). Does anyone knows that kind of box you need to run purify these days ? (looks like a license costs $780 in the US but $1100 in Sweden. hmm...) > The worst part of all this is ... it's still Windows. Some of us are OS agnostics, you know. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ast status, memory leaks, etc
On 11/21/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > I don't think there's a shortage of Windows boxes among the python-dev > crowd (I have plenty). Does anyone knows that kind of box you need to > run purify these days ? Dunno, but it would probably be fine on a reasonably new box with at least 1 GB of RAM. If you are interested in using purify for python, I think that would be great and doubt there would be an issue for the PSF to buy a copy. > (looks like a license costs $780 in the US but $1100 in Sweden. hmm...) There was also PurifyPlus (I think that was the name) for $1380 or so. My guess is that also included Quantify and the other program bundled together. > > The worst part of all this is ... it's still Windows. > > Some of us are OS agnostics, you know. Yeah, it was meant as a joke (though also my preference). Guess I shouldn't go on tour. :-) n ___ Python-Dev mailing list [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] svn diff -r {2001-01-01}
Greg Stein points out that because of the way the subversion
conversion was done, by-date revision specifications won't
work. Subversion assumes that time is monotonically increasing
over revions numbers - it does a binary search to find out
the revision that immediately precedes(?) the specified date.
Yet, as the conversion was done project-by-project (toplevel
svn dirs), commit time sometimes goes backward along with
increasing revision numbers; this breaks the algorithm
svn uses.
There are two way in which you might want to use date specifications
(that I can think of): svn diff (find the changes since some date)
and svn up (check out revision at some date). If you need to
do such operations, you will have to look up the closest
revision number manually (e.g. in viewcvs, or through svn log).
If this is a common operation, I'm sure it would be possible
to put a table of commit dates for python/ somewhere, to find
the necessary revision number more quickly.
For dates past the switchover, everything is fine. So
svn diff -r{00:00} Lib/
works fine.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31
On Thu, 17 Nov 2005 13:36:36 +1300 Tony Meyer <[EMAIL PROTECTED]> wrote: > > -- > AST for Python > -- > > As of October 21st, Python's compiler now uses a real Abstract Syntax > Tree (AST)! This should make experimenting with new syntax much > easier, as well as allowing some optimizations that were difficult > with the previous Concrete Syntax Tree (CST). > While there is no > Python interface to the AST yet, one is intended for the not-so- > distant future. OK, who is doing this ? I am mad keen to get this happening. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_cmd_line on Windows
Currently test_directories of test_cmd_line fails on the latest Python 2.4.2
from svn branch and from the svn head. The reason it seems is that the test
assumes that the local language of Windows is English and so tries to find
the string " denied" in the returned system error messages of the commands
("python .") and ("python < .").
But while it is true that the first command ("python .") does return an
English string error message even on so-called non-English versions of
Windows, the same does not seem to be true for the second command ("python <
."), which seems to return a locale-related string error message. And since
the latter test is looking for the English " denied" in a non-English
language formated string, the test fails in non-English versions of Windows.
Regards
Khalid
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: [Python-checkins] commit of r41497 - python/trunk/Lib/test
I just checked in the modification below. I'm not sure if this
behaviour is on purpose or by accident. Do we want to support hex
values in floats?
Do we want to support p, similar to e in floats?
Here are the lines from the test:
+self.assertEqual(float(" 0x3.1 "), 3.0625)
+self.assertEqual(float(" -0x3.p-1 "), -1.5)
n
-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Nov 21, 2005 9:17 PM
Subject: [Python-checkins] commit of r41497 - python/trunk/Lib/test
To: [EMAIL PROTECTED]
Author: neal.norwitz
Date: Tue Nov 22 06:17:40 2005
New Revision: 41497
Modified:
python/trunk/Lib/test/test_builtin.py
Log:
improve test coverage in Python/pystrtod.c and Python/mystrtoul.c.
Modified: python/trunk/Lib/test/test_builtin.py
==
--- python/trunk/Lib/test/test_builtin.py (original)
+++ python/trunk/Lib/test/test_builtin.py Tue Nov 22 06:17:40 2005
@@ -545,6 +545,34 @@
self.assertEqual(float(unicode(" 3.14 ")), 3.14)
self.assertEqual(float(unicode(" \u0663.\u0661\u0664
",'raw-unicode-escape')), 3.14)
+def test_float_with_comma(self):
+# set locale to something that doesn't use '.' for the decimal point
+try:
+import locale
+orig_locale = locale.setlocale(locale.LC_NUMERIC, '')
+locale.setlocale(locale.LC_NUMERIC, 'fr_FR')
+except:
+# if we can't set the locale, just ignore this test
+return
+
+try:
+self.assertEqual(locale.localeconv()['decimal_point'], ',')
+except:
+# this test is worthless, just skip it and reset the locale
+locale.setlocale(locale.LC_NUMERIC, orig_locale)
+return
+
+try:
+self.assertEqual(float(" 3,14 "), 3.14)
+self.assertEqual(float(" +3,14 "), 3.14)
+self.assertEqual(float(" -3,14 "), -3.14)
+self.assertEqual(float(" 0x3.1 "), 3.0625)
+self.assertEqual(float(" -0x3.p-1 "), -1.5)
+self.assertEqual(float(" 25.e-1 "), 2.5)
+self.assertEqual(fcmp(float(" .25e-1 "), .025), 0)
+finally:
+locale.setlocale(locale.LC_NUMERIC, orig_locale)
+
def test_floatconversion(self):
# Make sure that calls to __float__() work properly
class Foo0:
@@ -682,6 +710,7 @@
self.assertRaises(TypeError, int, 1, 12)
self.assertEqual(int('0123', 0), 83)
+self.assertEqual(int('0x123', 16), 291)
def test_intconversion(self):
# Test __int__()
___
Python-checkins mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] commit of r41497 -python/trunk/Lib/test
Neal Norwitz wrote:
> I just checked in the modification below. I'm not sure if this
> behaviour is on purpose or by accident.
Python 2.4 on Linux:
>>> float(" 0x3.1 ")
3.0625
Python 2.4 on Windows:
>>> float(" 0x3.1 ")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for float(): 0x3.1
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
