[squeak-dev] 4.1 - hashed collections still a problem
leves at elte.hu
Tue Mar 23 13:51:16 UTC 2010
On Tue, 23 Mar 2010, Adrian Lienhard wrote:
> Has it ever been considered to make the identity hash larger than 12 bits? Of course this is a trade off against space, but one that can be justified?!
> Just an idea: we could get rid of compact classes, which would give us additional 6 bits (5 bits from the compact class index plus 1 bit from the header type because there would only be 2 header types left). This would increase the identity hash values from 4096 to 262144. In a PharoCore1.0 image there are 148589 instances of compact classes, hence this would cost 580k. Or, we could just add an additional word and use the spare bits from the old identity hash for other stuff, e.g., immutability ;)
I like the first idea, we could even have the 17 continuous bits for
identity hash the 1 separate bit for immutability.
> On Mar 23, 2010, at 11:36 , Levente Uzonyi wrote:
>> How can we fix this?
>> I see two possible solutions for the problem:
>> 1) use #largeHash instead of #identityHash, which is the identity hash of the object mixed with the identity hash of its class. This helps if there are objects from different classes in the set, but it doesn't help with your benchmark. SystemTracer uses this method.
>> 2) use differently implemented collections which are optimized for your use case. For example I wrote LargeIdentitySet which probably has the best performance you can have: http://leves.web.elte.hu/squeak/LargeIdentitySet.st
>> (note that it's hardly tested, probably contains bugs)
More information about the Squeak-dev