[Python-3000] Dict literal bytecode

[Alexander Belopolsky]

On Tue, Mar 25, 2008 at 3:32 PM, Adam Olsen <rhamph at gmail.com> 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.