Nick Bastin writes:

There was some note in a presentation you gave quite a while ago that HotShot could profile C extension functions, but I believe that would have required a change to the main python interpreter loop. Does it

It would have required an interpreter change which, I believe, was never made. There may be a patch for this on SourceForge; I don't remember. You can search the patch and bug trackers for "hotshot" to see what's there; I afraid I don't remember the specific changes that were involved. The mechanism discussed at the time would have allowed measuring the time spent in calls to PyCFunction objects (extension functions), but would not have provided per-line information for those functions. The goals was as much to subtract the time spent in C code from the time allocated to the Python function itself more than to actually provide measurement of the C function itself (though some information falls out of that naturally). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Fred L. Drake, Jr. wrote:

Nick Bastin writes:

...

Does anybody know the current state of hotshot? I read on some of the twisted mailing lists a while back that someone tried it but had some problems (can't remember what off the top of my head...have to search the archives), and was wondering if it was regarded as complete (and if there was any documentation that talks about how the code coverage aspect is supposed to be used).

HotShot has had some attention, and has been found useful, but I don't think of it as really finished.

What's missing from hotshot is a little script that makes it possible to use hotshot from the command line (just like profile.py), i.e. something like this: import sys, os.path, hotshot, hotshot.stats prof = hotshot.Profile("hotshot.prof") filename = sys.argv[1] del sys.argv[0] sys.path.insert(0, os.path.dirname(filename)) prof.run("execfile(%r)" % filename) prof.close() stats = hotshot.stats.load("hotshot.prof") stats.sort_stats("time", "calls") stats.print_stats() The biggest problem I had with hotshot is the filesize. I was using the above script to profile a script which normally runs for about 10-15 minutes. After ca. 20 minutes the size of hotshot.prof was over 1 gig. Is there any possibility to reduce the filesize? Bye, Walter Dörwald

Skip Montanaro wrote:

Any objection if I check in the attached modification of your script as .../Tools/scripts/hotshotmain.py? It doesn't seem to work with the -p flag. Unfortunately, I have to take my son to hockey practice, so I can't debug that problem right now.

From modified script: ======================= profile = PROFILE for opt, arg in opts: if opt in ("-h", "--help"): usage() return 0 if opt in ("-p", "--profile"): profile = arg return 0 ======================== Should that second 'return 0' be there? Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268

Skip Montanaro wrote:

Walter> What's missing from hotshot is a little script that makes it Walter> possible to use hotshot from the command line (just like Walter> profile.py), i.e. something like this:

...

Walter,

Any objection if I check in the attached modification of your script as .../Tools/scripts/hotshotmain.py? It doesn't seem to work with the -p flag. Unfortunately, I have to take my son to hockey practice, so I can't debug that problem right now.

Maybe this script should use optparse instead of getopt? Bye, Walter Dörwald

Skip Montanaro wrote:

>> Any objection if I check in the attached modification of your script >> as .../Tools/scripts/hotshotmain.py? It doesn't seem to work with >> the -p flag. Unfortunately, I have to take my son to hockey >> practice, so I can't debug that problem right now.

Walter> Maybe this script should use optparse instead of getopt?

How would optparse be better than getopt, especially for simple use such as this?

I'd say, that all new stuff should use optparse. Bye, Walter Dörwald

On Mon, 2004-01-26 at 10:40, Guido van Rossum wrote:

...

Walter> Maybe this script should use optparse instead of getopt?

How would optparse be better than getopt, especially for simple use such as this?

Optparse is *always* better than getopt, once you're used to it. Even for a single option it's usually fewer lines of code.

And with Optparse it's much easier to add/remove options since each option's spec and handling is in one place, instead of spread out in several places. I do have a few minor nits with optparse though[1]. Even so, +1 on using Optparse for all new scripts. -Barry [1] e.g http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=842213

>> How would optparse be better than getopt, especially for >> simple use such as this?

Guido> Optparse is *always* better than getopt, once you're used Guido> to it. Even for a single option it's usually fewer lines Guido> of code.

Is this a pronouncement? A quick grep suggests that so far only Tools/scripts/diff.py uses optparse.

It's not a pronouncement -- it's just a recommendation. I see no need to start converting existing code to optparse -- but for all new code, I recommend it. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Mon, 2004-01-26 at 16:55, Guido van Rossum wrote:

...

It's not a pronouncement -- it's just a recommendation. I see no need to start converting existing code to optparse -- but for all new code, I recommend it.

Maybe the documentation should point people in the direction of optparse (e.g. by moving the optparse section ahead of getopt and putting a note like:

This module exists primarily for backwards compatibility - the optparse module is recommended for all new code.

at the top of the getopt section).

This sounds awfully close to deprecation of getopt. I don't want to go that far -- I don't want people to worry that getopt might go away. It won't. --Guido van Rossum (home page: http://www.python.org/~guido/)