Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I can't answer why the developer thought a faster hash was necessary. As to its quality as a hash function...

It's pretty poor, and slow on modern systems. It's known as the djb2 hash. (h << 5) + h is a way of writing 33*h without needing multipliers.

It fails pretty much every modern statistical test you can throw at it: https://gitlab.com/fwojcik/smhasher3/-/blob/main/results/per...

It's redeeming quality is that the code size is absolutely tiny, and that 33*h mod 2^64 is a reversible map, so if your input data is randomly distributed at least your output will be as well.



Thanks! Yeah, not being good was my expectation but I thought, if it was there, it had to have a good reason. I appreciate the input and confirmation, thankyou :)

Random distribution of outputs does seem to minimise collisions on as a small an input set as a list of processes so I suppose the risk of killing the wrong process is minimal. I do think if I used the app I’d replace it though.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: