Is MurmurHash overkill?
st.c implements MurmurHash to compute hash table indexes (#hash).
Simpler hash functions may be appropriate for hash tables, esp. small tables.
Is there a particular reason this hash function was chosen? Is MurmurHash typically used for check-summing purposes?
Anybody positively adverse to changing it? If so I won't bother. Otherwise I might take a crack at it.
#3 Updated by Yusuke Endoh almost 3 years ago
- Status changed from Assigned to Feedback
Simpler hash functions may be appropriate for hash tables, esp. small
Please make it quantitative when talking about performance.
Please show a benchmark first.
How slow is MurmurHash? How fast will st.c be if the algoritm
is replaced with another one?
And how much the drawback? That is, how many collision will
increase in actual cases?
Anybody positively adverse to changing it? If so I won't bother. Otherwise
I might take a crack at it.
Please make your move first.
We cannot answer your question until you show a benchmark.
Even after that, we cannot promise to import your patch before
you create it. The chicken or the egg :-)
Yusuke Endoh firstname.lastname@example.org
#4 Updated by Martin Bosslet almost 3 years ago
With the recent changes since hashDoS I'm not sure whether
we should really aim for simplicity. It's quite easy to
become a target with a function that is algebraically as
simple as for example DJB33X. But speed on the other hand
couldn't hurt. We use Murmur 2, there is a version 3 by
the same author who claims it is generally faster than 2.
Maybe we should give that a try first?