Manik,
If String's are dealt with by calling String.getBytes() which in turns
gets processed as a byte[], why is there such a big difference
SuperFastHash String speed and MurmurHash2 String speed (162 ms vs 56 ms)
but there's hardly any difference between the byte[] tests (29ms vs 40ms) ?
Cheers,
On Tue, 23 Mar 2010 18:44:11 +0100, Manik Surtani <manik(a)jboss.org> wrote:
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder ZamarreƱo
Sr. Software Engineer
Infinispan, JBoss Cache