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