> This is one of the reasons why many hashtable implementations introduce a random component into the algorithm. If the random component is a seed that can be

> This is one of the reasons why many hashtable implementations introduce a random component into the algorithm. If the random component is a seed that can be forced/stored/logged/reproduced then it's okay. Otherwise it's actually an horrible idea because it complicates debugging other issues. Randomness is the enemy, not the friend. > It also very nicely prevents security issues, since if the hashing algorithm is fixed, it can be exploited for denial of service by coming up with keys that all fall into the same bucket. Yeah, 20 years ago this was a thing to attack Java webservers: crafting URL with parameters so that they'd all end up in the same bucket. Big denial-of-service one. IIRC PHP webservers suffered from the exact same security issue. It was fixed by implementing a hash table with a seed and that seed was, of course, under the control of the dev because... Randomness is the enemy, not the friend.