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@email.com | Mobile: +61 409 573 268