Home Original page

profiler results for __getattr__, am I reading this correctly ?

Thomas Jensen thomasNO at SPAM.obscure.dk
Wed Oct 17 07:33:56 EDT 2001 
"Tim Peters" <tim.one at home.com> wrote in
news:mailman.1003288997.28703.python-list at python.org: 

> [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.

I'm delighted to hear that.

>> 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).

Thanks, I'll try that

> 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;

That sounds like what happened to me.

> 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. 

Ok, that would explain the other curious line in the output.

> 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. 

I'll look into it.

Thanks alot for the quick answer.

Now I can start looking for the real performance problems, like moving 
GUID's from objects to strings :-)

-- 
Best Regards
Thomas Jensen
More information about the Python-list mailing list