[Python-Dev] proposal+patch: sys.gettickeraccumulation()

[Nick Coghlan]

Ralf W. Grosse-Kunstleve wrote:
>   A pure Python program will spent the bulk of the time interpreting
>   bytecode.

Perhaps, perhaps not. A heck of a lot of the Python core isn't written 
in Python - time spent executing builtins, or running methods of builtin 
objects usually doesn't involve the main interpreter loop (we're 
generally in pure C-code at that point).

I'm curious how the suggested feature can provide any information that 
is actually useful for optimisation purposes. Just because a low 
proportion of time is spent in Python code, doesn't mean the Python code 
isn't at fault for poor performance.

As an example, in CPython 2.3 and earlier, this:

   result = ""
   for x in strings:
     result += x

is a lot worse performance-wise than:

   result = "".join(strings)

The first version does spend more time in Python code, but the 
performance killer is actually in the string concatenation C code. So 
the time is spent in the C code, but the fault lies in the Python code 
(In Python 2.4, the latter version is still faster, but the difference 
isn't as dramatic as it used to be).

Knowing "I'm spending x% of the time executing Python code" just isn't 
really all that interesting, unless you know *what* Python code is 
taking all the time. (e.g., if decimal.py spends all its time creating 
new instances of Decimal when running a benchmark, then you know to 
either speed up Decimal construction, or to look for temporary objects 
that can be eliminated, or both. Then you run the benchmark again to 
determine if the changes actually improved the situation)

I'd rather encourage people to write appropriate benchmark scripts and 
execute them using "python -m profile <benchmark>", rather than lead 
them up the garden path with a global "Python/non-Python" percentage 
estimation utility.

Cheers,
Nick.

-- 
Nick Coghlan               |     Brisbane, Australia
Email: ncoghlan at email.com  | Mobile: +61 409 573 268