I thought those results looked too good. 32-bit maths in js is always tricky, hence desire for tests, especially if one of the use cases is comparing compile-time and run-time hashes.
Cleaned up js implementation of murmur3 just to get something up quickly to assess murmur3 performance. It uses Math.imul or a shim for integer multiplication. Then created a pair of jsperfs:
In both tests, setup code is the same: pretty-printed closure-advanced-compiled code from my js-murmur3 implementation, and copy-pasted code from cljs's current number and string hashing.
Results are...interesting. So interesting that I am suspicious that something is wrong with my benchmarks or code. Perhaps you can have Mr. Egorov take a look? In summary:
- murmur3 int hash is about an 8% performance regression in firefox and safari.
- murmur3 string hash is more than double the speed of goog.string.hashCode on ff and safari for small strings, and even better for large ones.
- Except in chrome, where murmur3 is abysmal--about an order of magnitude regression on both ints and strings!
All these browsers have a native Math.imul, and Chrome's imul is definitely working. There must be something else making chrome's jit cranky.
I did not expect murmur3 to perform so well or so badly!