There may be many explanations, such as a different set of directories (and zipfiles) on sys.path
, automatically loaded/executed code at initialization, other processes running on the platform -- your code is not at all isolated nor repeatable, therefore its results are of very little value. Use python -mtimeit
to measure things much, much better.
Edit: some numbers...:
$ py26 -mtimeit 'q=2**1000000000; q+=3<<1000000000'
10 loops, best of 3: 466 msec per loop
$ py31 -mtimeit 'q=2**1000000000; q+=3<<1000000000'
10 loops, best of 3: 444 msec per loop
these accurately measure the +=
time (slightly better / more optimized in 3.1, repeatably). If you want to measure the shifting or raising to power times, then you can't use literals, of course (since literal expressions get computed at compile time, not at run time: part of why you want all your significant code to be in functions in modules, not in top-level code nor in your main script... so the compiler can do as much of the work as easily feasible, despite its lack of any serious optimizations;-). E.g.:
$ py31 -mtimeit -s't=2' 'q=t**1000000'
10 loops, best of 3: 19.4 msec per loop
$ py31 -mtimeit -s't=3' 'q=t<<1000000'
10000 loops, best of 3: 150 usec per loop
(just takes too long to do them with the larger RHS operand you're using and I'm getting impatient;-). Mixing the ops would of course be a sad disaster in terms of measuring, since the relatively fast ones would essentially disappear in the mix!-) Fortunately, there is no good reason for such mixing -- timeit
, after all, is for micro benchmarking!-)