M.-A. Lemburg wrote: > Still, here's the timeit.py measurement of the PythonFunctionCall > test (note that I've scaled down the test in terms of number > of rounds for timeit.py): > > Python 2.4: > 10 loops, best of 3: 21.9 msec per loop > 10 loops, best of 3: 21.8 msec per loop > 10 loops, best of 3: 21.8 msec per loop > 10 loops, best of 3: 21.9 msec per loop > 10 loops, best of 3: 21.9 msec per loop > > Python 2.5 as of last night: > 100 loops, best of 3: 18 msec per loop > 100 loops, best of 3: 18.4 msec per loop > 100 loops, best of 3: 18.4 msec per loop > 100 loops, best of 3: 18.2 msec per loop > > The pybench 2.0 result: > > PythonFunctionCalls: 130ms 108ms +21.3% 132ms 109ms +20.9% > > Looks about right, I'd say.
except for the sign, I'd say. pybench reported a slowdown from 108 to 130 ms, which prompted you to write > A little disturbing is the slow-down for Python function calls > and the built-in method lookup. Did anything change in these parts > of the interpreter ? but timeit is reporting a ~20% speedup (21.8 to 18 ms). on my machine, using the loop body from Calls.PythonFunctionCalls.test as a separate global function called by timeit, I get: 25 usec per loop for Python 2.4.3 22.5 usec per loop for Python 2.5 trunk which seems to match your timeit results quite well. and we *did* speed up frame handling on the reykjavik sprint. another sprint optimization was exception handling, and pybench did notice this (137 to 115 ms). here's what timeit says on my machine: 15.1 usec per loop for Python 2.4.3 23.5 usec per loop for Python 2.5 alpha 2 11.6 usec per loop for Python 2.5 trunk something's not quite right... </F> _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com