Speed quirk: redundant line gives six-fold speedup
python at rcn.com
Sat Aug 27 00:16:14 CEST 2005
> > 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.
> 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
Alternatively, if you want to be tricky, try something like this:
What this does and why it can improve search times is left as an
exercise for the reader :-)
More information about the Python-list