Well, that was just a though. You're right that long runs of constants can appear, and it's better to avoid pathological behaviour in such cases. Your second path looks good.
Eugene On Thu, Mar 10, 2011 at 6:30 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > 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