> A hash collision wouldn't matter that much.
Interesting. What was the use for the hash function then?
Take SHA3, which is around 50x slower than SeaHash. That is really really bad for hash tables.
When hash collisions happen in hash tables, they're resolved through collision-resolution strategy, such a linear proping.
Fingerprints are one very narrow usecase for hash functions, and there are tousands of other uses.
To avoid wasting cpu cycles preserving a property you don't need. Seahash should be 50x faster than sha3
For example, finding unique files on the file system. After looking at size, first and last bytes, it would be better to filter quickly on an imperfect hash (with, say, a 1 in 1^56 chance of collision) than slowly on a perfect hash (with a 1 in 1^256 chance).
http://aperiodical.com/2013/05/the-maths-of-star-trek-the-or...
Performance. Take a look at djb's (non-cryptographic) hash, with a constant multiplier chosen to be implemented with a shift and an add — that's the level of performance a non-cryptographic hash (e.g. for hash tables & similar purposes) needs.
In other words, you risk mapping `n` and `-n` to the same value under some modulus.