[Python-3000] Dict literal bytecode

[Adam Olsen]

On Tue, Mar 25, 2008 at 2:11 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> 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.)

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