[Python-3000] Dict literal bytecode
Adam Olsen
rhamph at gmail.com
Tue Mar 25 21:26:44 CET 2008
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
More information about the Python-3000
mailing list