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.
Comments
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.