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.) > 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. > 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. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
