generator expressions: performance anomaly?

[Diez B. Roggisch]

> 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
> languages.

Most probably. But I don't see much code of that type that it would be worth
optimizing for, either. The cost for re-evaluation such an expression
doesn't really account for any performance problems you hit - in python, of
course.
See this:

deets at kumquat:/usr/lib/python2.3$ python timeit.py -c "[4*5 for i in
xrange(10000)]"
100 loops, best of 3: 5.5e+03 usec per loop
deets at kumquat:/usr/lib/python2.3$ python timeit.py -c "[20 for i in
xrange(10000)]"
100 loops, best of 3: 4.3e+03 usec per loop


Now of course the longer the expressions get, the more time it costs - but
how many long arithmetical expression of constant evaluation value do you
have?

> 
> 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.

This analysis would only be possible for the most primitive of examples, 
the reason beeing that due to the dynamic features syntactically equivalent
expressions can have totally different semantics. So its not really worth
the effort.

-- 
Regards,

Diez B. Roggisch