On Thu, 10 Mar 2011 02:17:34 +0000 (UTC) Eugene Toder <eltoder at gmail.com> wrote: > > Indeed, see http://bugs.python.org/issue11244 > > Yes, I've noticed that too. However, if I'm not missing something, your patches > do not address folding of -0. > > Btw, there's an alternative approach to allow "recursive" constant folding. > Instead of keeping a stack of last constants, you can keep a pointer to the > start of the last (LOAD_CONSTs + NOPs) run and the number of LOAD_CONSTs in > that run (called lastlc in the current version). When you want Nth constant > from the end, you start from that pointer and skip lastlc-N constants. You > also make a function to get next constant from that point. This approach has > worse time complexity for searching in a long run of LOAD_CONSTs, Yes, the stack basically acts as a cache to avoid computing all this again and again. > however, > there are upsides: > - very long runs of constants are rare in real code True, but they might appear in generated code. > - it uses less memory and doesn't have arbitrary limits on the size of the run Neither does the latest patch. > - it's book-keeping overhead is smaller, so when you don't have long runs of > constants (common case, I believe), it should be faster The book-keeping overhead should be quite small really, it's a simple autogrowing array with O(1) access and amortized append time. What's left is the overhead of the initial malloc() (and final free()). > - I think it's simpler to implement Feel free to propose an alternate patch, but I'm not sure that it would be significantly simpler (and a stack is a well-known data structure). Also, please present some benchmarks if you do. Regards Antoine.
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