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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4