The performance of larger prime multipliers seems intuitively better, but it isn't necessarily so. If a better quick hash step is desired, a round of murmur would be much better.
For instance, one of the constants in the murmur hash finalizer is even. Reading about the weaknesses of murmur 2 is very instructive. The lesson is that picking numbers from thin air isn't a great idea. Knuth also has some very good (if very old and dated) material on the topic. The first question is whether this matters. Is a significant chance of collision actually even material? If yes, using a high quality hash like murmur3 should be tested. Especially if the hash can be cached, the cost is often surprisingly low. Sent from my iPhone > On Jan 29, 2016, at 12:25, Julian Hyde <[email protected]> wrote: > > A larger prime would probably give better hashes (e.g. 524287 == 2 ^ 19 - 1) > and could still be computed using a single shift and subtract. > > A few hash functions such as Util.hash(int, int) still use just shift and > xor. They should definitely be fixed. I have logged > https://issues.apache.org/jira/browse/CALCITE-1071.
