Logged In: YES 
user_id=34209

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]
    items.sort()
    items.reverse()
    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.