[Python-checkins] CVS: python/dist/src/Objects dictobject.c,2.86,2.87

Tim Peters tim_one@users.sourceforge.net
Sat, 12 May 2001 17:19:34 -0700


Update of /cvsroot/python/python/dist/src/Objects
In directory usw-pr-cvs1:/tmp/cvs-serv1323/python/dist/src/Objects

Modified Files:
	dictobject.c 
Log Message:
Get rid of the superstitious "~" in dict hashing's "i = (~hash) & mask".
The comment following used to say:
	/* We use ~hash instead of hash, as degenerate hash functions, such
	   as for ints <sigh>, can have lots of leading zeros. It's not
	   really a performance risk, but better safe than sorry.
	   12-Dec-00 tim:  so ~hash produces lots of leading ones instead --
	   what's the gain? */
That is, there was never a good reason for doing it.  And to the contrary,
as explained on Python-Dev last December, it tended to make the *sum*
(i + incr) & mask (which is the first table index examined in case of
collison) the same "too often" across distinct hashes.

Changing to the simpler "i = hash & mask" reduced the number of string-dict
collisions (== # number of times we go around the lookup for-loop) from about
6 million to 5 million during a full run of the test suite (these are
approximate because the test suite does some random stuff from run to run).
The number of collisions in non-string dicts also decreased, but not as
dramatically.

Note that this may, for a given dict, change the order (wrt previous
releases) of entries exposed by .keys(), .values() and .items().  A number
of std tests suffered bogus failures as a result.  For dicts keyed by
small ints, or (less so) by characters, the order is much more likely to be
in increasing order of key now; e.g.,

>>> d = {}
>>> for i in range(10):
...    d[i] = i
...
>>> d
{0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9}
>>>

Unfortunately. people may latch on to that in small examples and draw a
bogus conclusion.

test_support.py
    Moved test_extcall's sortdict() into test_support, made it stronger,
    and imported sortdict into other std tests that needed it.
test_unicode.py
    Excluced cp875 from the "roundtrip over range(128)" test, because
    cp875 doesn't have a well-defined inverse for unicode("?", "cp875").
    See Python-Dev for excruciating details.
Cookie.py
    Chaged various output functions to sort dicts before building
    strings from them.
test_extcall
    Fiddled the expected-result file.  This remains sensitive to native
    dict ordering, because, e.g., if there are multiple errors in a
    keyword-arg dict (and test_extcall sets up many cases like that), the
    specific error Python complains about first depends on native dict
    ordering.


Index: dictobject.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/dictobject.c,v
retrieving revision 2.86
retrieving revision 2.87
diff -C2 -r2.86 -r2.87
*** dictobject.c	2001/05/10 21:45:19	2.86
--- dictobject.c	2001/05/13 00:19:31	2.87
***************
*** 189,198 ****
  	   and 0 < incr < ma_size and both are a function of hash.
  	   i is the initial table index and incr the initial probe offset. */
! 	i = (~hash) & mask;
! 	/* We use ~hash instead of hash, as degenerate hash functions, such
! 	   as for ints <sigh>, can have lots of leading zeros. It's not
! 	   really a performance risk, but better safe than sorry.
! 	   12-Dec-00 tim:  so ~hash produces lots of leading ones instead --
! 	   what's the gain? */
  	ep = &ep0[i];
  	if (ep->me_key == NULL || ep->me_key == key)
--- 189,193 ----
  	   and 0 < incr < ma_size and both are a function of hash.
  	   i is the initial table index and incr the initial probe offset. */
! 	i = hash & mask;
  	ep = &ep0[i];
  	if (ep->me_key == NULL || ep->me_key == key)
***************
*** 302,309 ****
  	/* We must come up with (i, incr) such that 0 <= i < ma_size
  	   and 0 < incr < ma_size and both are a function of hash */
! 	i = (~hash) & mask;
! 	/* We use ~hash instead of hash, as degenerate hash functions, such
! 	   as for ints <sigh>, can have lots of leading zeros. It's not
! 	   really a performance risk, but better safe than sorry. */
  	ep = &ep0[i];
  	if (ep->me_key == NULL || ep->me_key == key)
--- 297,301 ----
  	/* We must come up with (i, incr) such that 0 <= i < ma_size
  	   and 0 < incr < ma_size and both are a function of hash */
! 	i = hash & mask;
  	ep = &ep0[i];
  	if (ep->me_key == NULL || ep->me_key == key)