Fix typos and add some elaborations

This commit is contained in:
Raymond Hettinger 2004-03-15 15:52:22 +00:00
parent cd1e8a9485
commit 9d5c44307a

View file

@ -94,7 +94,7 @@ Tunable Dictionary Parameters
* Growth rate upon hitting maximum load. Currently set to *2.
Raising this to *4 results in half the number of resizes,
less effort to resize, better sparseness for some (but not
all dict sizes), and potentially double memory consumption
all dict sizes), and potentially doubles memory consumption
depending on the size of the dictionary. Setting to *4
eliminates every other resize step.
@ -112,6 +112,8 @@ iteration and key listing. Those methods loop over every potential
entry. Doubling the size of dictionary results in twice as many
non-overlapping memory accesses for keys(), items(), values(),
__iter__(), iterkeys(), iteritems(), itervalues(), and update().
Also, every dictionary iterates at least twice, once for the memset()
when it is created and once by dealloc().
Results of Cache Locality Experiments
@ -191,6 +193,8 @@ sizes and access patterns, the user may be able to provide useful hints.
is not at a premium, the user may benefit from setting the maximum load
ratio at 5% or 10% instead of the usual 66.7%. This will sharply
curtail the number of collisions but will increase iteration time.
The builtin namespace is a prime example of a dictionary that can
benefit from being highly sparse.
2) Dictionary creation time can be shortened in cases where the ultimate
size of the dictionary is known in advance. The dictionary can be
@ -199,7 +203,7 @@ sizes and access patterns, the user may be able to provide useful hints.
more quickly because the first half of the keys will be inserted into
a more sparse environment than before. The preconditions for this
strategy arise whenever a dictionary is created from a key or item
sequence and the number of unique keys is known.
sequence and the number of *unique* keys is known.
3) If the key space is large and the access pattern is known to be random,
then search strategies exploiting cache locality can be fruitful.
@ -228,11 +232,12 @@ The dictionary can be immediately rebuilt (eliminating dummy entries),
resized (to an appropriate level of sparseness), and the keys can be
jostled (to minimize collisions). The lookdict() routine can then
eliminate the test for dummy entries (saving about 1/4 of the time
spend in the collision resolution loop).
spent in the collision resolution loop).
An additional possibility is to insert links into the empty spaces
so that dictionary iteration can proceed in len(d) steps instead of
(mp->mask + 1) steps.
(mp->mask + 1) steps. Alternatively, a separate tuple of keys can be
kept just for iteration.
Caching Lookups