Speed quirk: redundant line gives six-fold speedup

[Raymond Hettinger]

[Raymond Hettinger]
> > With respect to
> > distribution, it should be noted that string hash values are decidely
> > non-random and your variable names likely congested consecutive spaces
> > in a nearly full table (resulting in seven times as many search probes
> > to find a global value).
> >
> > When the extra value was added, it likely resized the table four-fold
> > and redistributed the hash values into fewer consecutive positions.

[Benjamin Niemann]
> If that's the cause, then here's another reason to use long, descriptive
> names instead of C64-BASIC style a, b, c, i, j... - with long names the
> chances of hash collisions are pretty low.
> Or everyone will start optimizing their programs by using long, *random*
> names ;)

The wink applied to second line but could have also applied to the
first.  For the most part, the non-randomness of string hashes tends to
work in your favor -- it can result in collision free hash tables.

For optimization, the best approach is to use local variables in your
innermost loops.

Alternatively, if you want to be tricky, try something like this:

   globals().update(globals())

What this does and why it can improve search times is left as an
exercise for the reader :-)


Raymond