Python Speed

[Stefan Behnel]

Steven D'Aprano, 28.02.2013 08:05:
> On Wed, 27 Feb 2013 21:11:25 -0500, Terry Reedy wrote:
> 
>> There is a problem with timer overhead for sub-microsecond operations.
>> In interactive use, the code is compiled within a function that gets
>> called. The string 'abc需' should be stored as a constant in the code
>> object. To force repeated string operation, one should either time from
>> command line or do an operation, as with the example above. I notice
>> that the first of 3 times is almost always higher for some reason.
> 
> I am not an expert on this, but I suspect the problem may have something 
> to do with CPU pipelines and cache. The first time the timer runs, the 
> cache is empty, and you get a slightly higher time. Subsequently there 
> are not as many CPU cache misses, and the code runs more quickly.

Well, the default loop iteration count is 1000000, so warming up any caches
might make a little difference at the very beginning but should rarely have
a major impact on the overall running time, as each iteration only changes
the final result by 1/1000000 of its runtime.

However, it's best to run timeit as a main program (python -m timeit),
because the way it works then is that it first runs the code a couple of
times to see how often it should repeat it in a loop to get meaningful
results. Only *then* it starts benchmarking it. That initial testing phase
should usually be enough to warm up any caches, so that you'd get better
results. You can still get the results of all repeated runs if you pass -v.

Stefan