3 ms·
Yes, speed for normal inputs is what's generally desired. A faster hash function can yield better overall performance than having fewer collisions. Here's some
by Scaevolus 10y ago
Yes, speed for normal inputs is what's generally desired.
A faster hash function can yield better overall performance than having fewer collisions. Here's some empirical evidence for this: https://www.strchr.com/hash_functions https://www.strchr.com/hash_functions
The speed is correlated only weakly with the number of collisions-- and using the modern x86 CRC32 instruction yields the best results.
- nickpsecurity 10y agoI suggest somebody test SpookyHash-128 similarly to those to see how it performs. Designed to be collision resistant and fast. http://www.burtleburtle.net/bob/hash/spooky.html http://www.burtleburtle.net/bob/hash/spooky.html
- CiPHPerCoder 10y agoWhy not SipHash? https://www.131002.net/siphash/ https://www.131002.net/siphash/
- nickpsecurity 10y agoCuz I either forgot it or never heard of it. Also looks to be one Perl comments are referencing. Has good performance and published cryptanalysis. That's awesome! Looks to be good default for this sort of thing. Thanks for the link. Definitely going in bookmarks & probably future apps :)