This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author twouters
Date 2003-05-02.12:53:14
SpamBayes Score
Marked as misclassified
Logged In: YES 

Well, I just re-used the call-profiling stuff that Jeremy (I
think) already put in, but I don't see much use for getting
people to run it. It shows the expected number of CALL_ATTR
uses in e.g. pystone, no unexpected overheads inside modules
or anything.

The problem with the code isn't mispredicted branches, but
general slowdown if *none* of the branches are taken. The
only result I can think of of having people run with
call-profiling on would be to find out we need to
special-case other common tp_getattro functions -- which
would result in more code and thus likely more general slowdown.

However, patch with CALL_PROFILEing atatched. The call
profile code changed somewhat, as this code returns a dict
of counters, instead of a tuple. I found a 21-element tuple
somewhat unwieldy :) I use a code snippet like:

    print "Call stats:"
    items =  sys.callstats().items()
    items = [(value, key) for key, value in items]
    for value,key in items:
        print "%30s: %30s"%(key, value)

at the end of testing code (pystone, regrtest, etc.) Don't
forget to #define CALL_PROFILE somewhere.
Date User Action Args
2007-08-23 15:21:37adminlinkissue709744 messages
2007-08-23 15:21:37admincreate