Simple question about how the optimizer works

Jeff Epler jepler at unpythonic.net
Thu May 9 12:34:11 EDT 2002


On Thu, May 09, 2002 at 08:52:28AM -0700, James J. Besemer wrote:
 
> I'd expect there'd be more to gain in Python simply looking for patterns such as
> 
>     for i in xrange(N): ...

The expression giving the object to iterate over in a 'for' loop is
evaluated only when the 'for' loop begins, not at each iteration.

That's completely different than
    print xrange(3), xrange(3)
where xrange must be called twice.  Not even the 'LOAD_GLOBAL xrange' 
instruction can be hoisted/factored.  For instance, imagine the following
(perverse) definition of xrange:

    builtin_xrange = xrange
    def xrange(x):
	global xrange
	xrange = lambda x: "My dog has fleas"
	return builtin_xrange(x)

Python doesn't have anything like
    proclaim_const(xrange)
    proclaim_pure(xrange)
to let the compiler know that xrange is not subject to modification,
side-effects, and does not depend on any global state.

Of course, then there's the situation
    def f(x):
	g(xrange(x), xrange(x))
	g(xrange(x), xrange(x))
Here, there would still be at least two xrange calls, since x might be
mutable and modified (through another name, or because xrange = lambda
x:x) by the call to g.  (This assumes g is not pure, of course)  In
general any mutable object can be modified at any call, and in general
you can't predict that an object is immutable at compile-time.

So now you get to write
    def f(x):
	assert_immutable(x)
	g(xrange(x), xrange(x)
	g(xrange(x), xrange(x))
and add compiler support (just like you added for proclaim_*())

Get busy ..

Jeff





More information about the Python-list mailing list