Scott A Crosby wrote:
> 
> On Sun, 9 Dec 2001, Stephan Rudlof wrote:
> 
> 
> > But for ordinary - not VM related - hashed collections an alternative hash
> > scheme with VM support (named #longHash?) could make sense. And the use of
> 
> Its probably not relevant. My hashed collection stuff avoids a nasty big
> performance degradation for when you get to >4000 elements (where
> performace will fall by a factor of 1000 as the algorithm devolves into a
> linear search).. If someone needs to store >100k objects in a hash table,
> they'll probably be far better served by writing a custom 'hash' function
> and store a 30-bit hash value in a slot.

One last - hopefully ;-) - point:
Why not building support for the changed ProtoObject>>identityHash named
e.g. #longHash into the VM?
Answer: there is only about a 25% performance loss for a *very* simple loop
for the ST version:

[100000 timesRepeat: ['hy!' longIdentityHash]] timeToRun
 586 586 586
[100000 timesRepeat: ['hy!' identityHash]] timeToRun
 467 466 471

The methods for this test in ProtoObject:

longIdentityHash
	^ self identityHash * 4097

identityHash
	"Answer a SmallInteger whose value is related to the receiver's identity.
	This method must not be overridden, except by SmallInteger.
	Primitive. Fails if the receiver is a SmallInteger. Essential.
	See Object documentation whatIsAPrimitive.

	Do not override."

	<primitive: 75>
	self primitiveFailed

This isn't worth introducing a new prim, isn't it?


Greetings,

Stephan

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3