Georg Brandl ge...@python.org added the comment:
Freshed up and committed in r85451.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3865
___
Sandro Tosi sandro.t...@gmail.com added the comment:
Hello,
Here's a patch that implement what's request by Fredrik.
Regards,
Sandro
--
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19188/issue3865-py3k.patch
___
Python
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3865
___
Fredrik Lundh [EMAIL PROTECTED] added the comment:
(the reason this is extra bad for C modules is that the profilers
introduce overhead for Python code, but not for C-level functions. For
example, using the standard profiler to benchmark parser performance for
xml.etree.ElementTree vs.
New submission from Fredrik Lundh [EMAIL PROTECTED]:
You often see people using the profiler for benchmarking instead of
profiling. I suggest adding a note that explains that the profiler
modules are designed to provide an execution profile for a given
program, not for benchmarking different
