profiler results for __getattr__, am I reading this correctly ?

[Tim Peters]

[Thomas Jensen]
> I'm working on a Gnutella client, and were beginning to look a bit at
> performance.
> After running it through the profiler module, it seems most of the time
> is spent in asyncore.dispatcher's __getattr__ method.
> (used for socket pseudo-inheritance AFAIR).
> My question is, can this be true?,

Certainly, but unlikely.

> or am I reading the results incorrectly ?

Probably not, and more likely that the results are incorrect.

Try grabbing profile.py out of the current CVS tree (it should run fine
under 2.1.1 too, and under 2.0.1).  There was a systematic bug that caused
time to get charged to the wrong functions, when a Python exception got
raised by Python code but caught and cleared by C code before returning to
Python.  For example, hasattr() routinely screwed up profiling results.  One
symptom is tiny functions reported to take mountains of time when you're
pretty sure they don't; another symptom is the profiler reporting that a
function you know darned well isn't recursive was actually involved in
recursive calls.  All that was due to the profiler's view of the call stack
getting out of synch with reality by one frame.  The bug existed for years,
and was just fixed within the last couple of weeks.

Note that the current (CVS) profile.py also has a new, more accurate, and
less intrusive calibration procedure.  Calibrating the profiler for the box
it's running on can be important.  Docs for that can be gotten from CVS, or
from 2.2b1 to be released this Friday.