How much does Python optimize?

Alex Martelli aleaxit at
Fri Mar 3 22:08:44 EST 2006

Blackbird <fake at> wrote:
> >> for i in range(10):
> >>     <some code that depends on i>
> > Yup, and if you are tuning a piece of code to the wall, you should
> > time it and possibly care.  Likely you are not, and the timing makes
> > no difference.  Someday, range will behave like xrange automagically,
> Thanks. Yes, this will be a problem for iterations in the order of 10**5 and
> upwards only, and those are rare in most applications.  So my question was

And not crucial when they happen, mostly:

helen:~ alex$ python -mtimeit -s'x=10**5' 'for i in range(x): j=i*i'
10 loops, best of 3: 102 msec per loop

helen:~ alex$ python -mtimeit -s'x=10**5' 'for i in xrange(x): j=i*i'
10 loops, best of 3: 80.9 msec per loop

a 20% difference (for a very lightweight loop body), while measurable,
will matter at all only in the hottest of hotspots, the narrowest of
bottlenecks. Anyway, do learn about -mtimeit, it's cool indeed for such
performance measurements.

> more motivated by a general curiosity about the inner workings of the Python
> interpreter, and I sort of understand why advanced optimization on an
> instruction set like bytecode would be difficult.  And in the mean time, I

Python deliberately avoids all sorts of optimizations, including obvious
ones such as constant hoisting -- the idea being that when you need
something hoisted, you can hoist it yourself, and meanwhile by knowing
that the compiler is dirt-simple and literal-minded you avoid all kinds
of risks connected to optimizer bugs or misunderstandings thereof.


More information about the Python-list mailing list