On Sun, 9 Dec 2001, Stephan Rudlof wrote:

> > My collection changes were discounted on the list and may be obsolete...
>
> Why?
>

Whoops... What this means is that my SortedCollection changes (which made
macrobenchmark1 about 33% faster) may be obsolete.

My *{Set,Dictionary} changes are all relevant..

> One remark:
> There are just 12 hash bits in the object header, an identityHash has to be
> consistent with the hash stored there (at least for MethodDictionaries, look
> for #hashBitsOf: in Interpreter>>lookupMethodInDictionary:).

Actually, no... The MethodDictionary has to be consistent with the
hashbits. Nothing says that idenityHash has to be consistent. I refactored
this code into identiryHash and hashBits.

> 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.

Scott