Andreas Raab wrote:

Did you ever look at Integer>>hash?! From the above it seems as if you
are assigning values that hash particularly bad. Try the following on
your map:

=========

No I haven't.  But I see that you are absolutely write about the poorly
dispersed hash values it generates among large integers, causing lots of
collisions.

I looked up the LargeInteger>>hash method in VisualAge, the fastest Smalltalk
I've used.  It says:

  ^self bitAnd: 16r3FFFFFFF

This allowed 100% dispersion using your tests and actually made the removeKey:
test I posted earlier run as fast as with SmallIntegers!

((100 factorial to: 100 factorial + 10000) collect: [ :e | e bitAnd:
16r3FFFFFFF ]) asSet size

Now I'm scratching my head again because you and Stephen seem to be right about
the LargeInteger comparisons not being a problem, as this test shows:

| a b |
a _ (100 factorial to: 100 factorial + 100000) asArray shuffled.
b _ a copy shuffled.
[ a with: b do: [ :eachA :eachB | a = b ] ] timeToRun 

Even with a few collisions, I'm perplexed why removing 2001 keys takes **5
hours**..!

Adding #hash to LargeInteger might be an alternative to changing my oid ranges
to be < 32-bits, but it might be hard for some to want to put that in their
image.  Right now, Magma doesn't make a single system change.  I would consider
it a "system" change.

Is it a safe one?

Thank you!
  Chris

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com