Some very early results,
http://pastie.org/883111
Only testing MurmurHash2 (endian-neutral variant which is 2x as slow as the original algo)
and SuperFastHash. I haven't implemented FNV-1 as yet.
Some notes:
* Test was run over 100k random keys
* Max size for a String and byte[] key set to 16. Actual size is a random number between
1 and MaxSize.
* Functions mainly implemented to handle byte[]'s.
* Functions handle Strings by calling String.getBytes(). The bulk of the time spent in
String keys is therefore attributed to String.getBytes().
* Functions handle Object hashcodes by taking the int hashcode and creating a 4-element
byte[] out of it. Again, the bulk of the time spent here is in this conversion.
* Keys generated before any measurements taken, a full cycle run to warm up the hotspot
compiler as well.
Looks like MurmurHash2, despite using the slower version to accommodate CPU endian neutral
behaviour, is winning in terms of distribution. And by a fair way too.
For those interested in the test and the hash impls, have a look at this (dependency on
Apache commons-math):
http://pastie.org/883135
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org