Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps
Ulf.Zibis at gmx.de
Wed May 23 23:58:07 UTC 2012
What about making this approach a little bit more general?
See: Bug <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812862>6812862
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812862> - provide customizable hash() algorithm
in HashMap for speed tuning
+ all later comments.
Then you additionally could save:
if ((0 != h) && (k instanceof String))
Looking at the codes of many charsets, the main variance seems to be in the lower 8 bits of a
character, especially if the strings belong to the same language. So if we would compose the initial
32-bit values from 4 chars then the murmur3 algorithm could perform almost twice faster.
If you alter all hash maps in JDK to use a new hash value, which noteworthy use cases remain to use
the legacy hashcode()? Do we really need 2 hash fields in String?
In project coin, we have set in stone to use compile time hashes for Strings_in_switch extension. So
it never can't profit from the murmur3 optimization. IMO: what a pity!
(Prominent people have said, it will never make sense to change the String's hash algorithm.)
Am 23.05.2012 21:03, schrieb Mike Duigou:
>> Also, this change
>> - return h ^ (h>>> 7) ^ (h>>> 4);
>> + h ^= (h>>> 7) ^ (h>>> 4);
>> + return h;
>> will make the compiler generates an additional iload/istore pair.
>> While the Jitted code will be the same, it may bother the inlining heuristic.
return (h ^= (h>>> 7) ^ (h>>> 4));
have the same effect ?
Anyway, please add a comment for later readers.
More information about the core-libs-dev