On Thu, 10 Mar 2011 02:17:34 +0000 (UTC) Eugene Toder <elto...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
