On Tue, Mar 25, 2008 at 2:11 PM, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > On Tue, Mar 25, 2008 at 3:32 PM, Adam Olsen <[EMAIL PROTECTED]> wrote: > .. > > I worry that there might be generated code using disgustingly large > > literals. > > I don't see how this would presents a bigger problem to the stack > scheme compared to the current insert as you go scheme. Note that > for "disgustingly large" (>65535 elements) literals, the current code > does not preallocate the hash table. This means that the hash table > may need to be reallocated during dict creation, which is certainly > more expensive than the extra stack space. > > > Does batch creation still work for that? > > I don't understand. What is "batch creation?" (If this is something > related to py2exe, then I have no idea.)
Sorry, I wasn't clear here. I meant that there may be disgustingly large globals that exceed some maximum size the stack allows. Performance is not an issue as it is done only once. Can you confirm/disprove that the maximum size will be the same after as it was before? By "batch" I only mean that you load all the constants onto the stack, then process them in a single pass, rather than loading and processing as you go. > > Guido's support for frozenset was later withdrawn: > > http://mail.python.org/pipermail/python-3000/2008-January/011868.html > > > > I missed that. However, we peephole optimizer can still use the same > trick as I proposed for dict literals. > > > > In certain contexts, such as "if i in {1, 2, 3}:", you can reuse the > > literal regardless of whether it's a set or a frozenset. I don't know > > if anybody has begun implementing that though. > > > > Do you suggest that peephole optimizer can detect cases when set > literal is not bound and replace it with a frozenset constant? This > looks like a worthwhile optimization that should also work for list > literals. At the very least the optimizer should be able to deal with > the frozenset({...}) case. It does not even have to be a frozenset. A set works just as well, never modified by the produced bytecode. > > Playing around a bit, I've found that "_x = {1, 2, 3}; x = set(_x)" > > (assuming _x were precomputed) is faster for larger literals, with the > > break even point at about 10. Perhaps you could investigate that as > > well? > > I think you mean it is faster than "x = {1, 2, 3}." This is exactly > the speed-up that I am hoping to exploit. The set(_x) constructor > does not need to recompute the hash values that are already stored in > _x. Ahh, yes. -- Adam Olsen, aka Rhamphoryncus _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
