[Python-Dev] On the possibility of "optimizing" range() calls in for-loops

[Chad Netzer]

On Sun, 2003-06-15 at 20:59, Raymond Hettinger wrote:

> The SF patch manager has a workable implementation of your idea:
> 
>     www.python.org/sf/738094  for i in range(N) optimization 
> 
> 
> The jury is still out on whether it is an elegant, brilliant patch or
> a horrendous hack.

Thanks for pointing out this patch to me.  It was a bit of a revelation,
since I had been looking at this issue from more of a byte code
generation and special casing standpoint, whereas this approach peeks
ahead right inside the range() builtin C implementation.  That makes it
quite straightforward, doesn't change the bytecode generation at all,
and nicely gets around all the issues I brought up in my original post
(ie. overriding the range() builtin, and handling python 2.3 PyLong
valued ranges (by not optimizing in those cases)).

Of course, I can see why it might cause some people to cringe, just
because it is snooping ahead in the frame.  But, it doesn't seem that
the value of 3 is likely to change often, so it probably won't add much
of a maintainance burden.

Hopefully this patch can be discussed further once 2.4 starts to be
talked about.  I think I'll try to gather some statistics on how often
this optimization would be employed in existing code bases, and thus,
how much of a speed/memory gain it is likely to give on average.  My
intuition is that the small overhead it introduces will be more than
made up for by the speed and memory use improvements it can bring.

-- 
Chad Netzer <cnetzer at sonic dot net>