Rev 3820: Comment about using using 0xFFFFFFFF as part of _search_key_255 in http://bazaar.launchpad.net/%7Ebzr/bzr/brisbane-core

[John Arbash Meinel]

At http://bazaar.launchpad.net/%7Ebzr/bzr/brisbane-core

------------------------------------------------------------
revno: 3820
revision-id: john at arbash-meinel.com-20090218161311-45hzcqxfqus6fdtg
parent: v.ladeuil+lp at free.fr-20090218092113-ld7s24aqzt65v216
committer: John Arbash Meinel <john at arbash-meinel.com>
branch nick: brisbane-core
timestamp: Wed 2009-02-18 10:13:11 -0600
message:
  Comment about using using 0xFFFFFFFF as part of _search_key_255
-------------- next part --------------
=== modified file 'bzrlib/chk_map.py'
--- a/bzrlib/chk_map.py	2009-02-18 09:21:13 +0000
+++ b/bzrlib/chk_map.py	2009-02-18 16:13:11 +0000
@@ -80,6 +80,12 @@
     # http://docs.python.org/library/zlib.html recommends using a mask to force
     # an unsigned value to ensure the same numeric value (unsigned) is obtained
     # across all python versions and platforms.
+    # Note: However, on 32-bit platforms this causes an upcast to PyLong, which
+    #       are generally slower than PyInts. However, if performance becomes
+    #       critical, we should probably write the whole thing as an extension
+    #       anyway.
+    #       Though we really don't need that 32nd bit of accuracy. (even 2**24
+    #       is probably enough node fan out for realistic trees.)
     bytes = '\x00'.join([struct.pack('>L', zlib.crc32(bit)&0xFFFFFFFF)
                          for bit in key])
     return bytes.replace('\n', '_')