generator expressions: performance anomaly?
apardon at forel.vub.ac.be
Tue Jan 18 09:05:15 EST 2005
Op 2005-01-18, Diez B. Roggisch schreef <deetsNOSPAM at web.de>:
>> Something else I was thinking about. I think it would be nice if the
>> python compilor could figure out whether a genexp in a list or tuple
>> expression always generates the same list or tuple and then instead
>> of generating code would generate the list or tuple in place.
> This won't ever happen in python - at least not in python otherwise similar
> to the one we know...
> The thing you're after is known as "common subexpression elemination" and
> can only be done in purely functional languages. While that certainly is an
> interesting property of a language, it e.g. forbids functions like
> time.time() - a too huge paradigm shift for python.
I don't see how generating byte code for a = 9; when seeing the
expression a = 3 + 6, would be a problem for non-functional
I agree that things like [time.time() for i in xrange(10)] shouldn't
be pregenerated and that the problem is more complicated as I thought.
But during compilation the compilor could do an anlysis of the code
do determine whether there are side effects or not. If the compilor
then would store a code in the byte code for functions that are
guaranteed side-effect free and only pregenerated objects generated
by expressions with no side-effect, some common subexpression
elimination could be done even in a non-functional language.
More information about the Python-list