P.S. I have no idea how to calculate the number of slots to get the best performance from a hash table with N entries. But the following analogy suggests that a significantly higher number of slots should be used than anyone has previously suggested.
Q: How many slots are needed for a hash table with 23 entries in order to have a probability > 50% that every entry will be in a separate slot?
A: 366
I know this sounds improbable, but the reverse of this is a well known mathematical puzzle:
Q: How many students do you need in a class to have a probability that two or more share a birthday > 50%?
A: 23
Obviously, the overhead to iterate over two or five or even ten entries on a slot is not going to be that significant, and the mathematics is much more complicated, but the moral seems reasonably clear: if you are doing hash table look-ups by item name, then using a large number of slots might help performance a lot without using a huge amount of memory.
OTOH if you are iterating using $hget(table,n) or using $hfind - both of which need to iterate over the entire table - you might as well use -m1 for a single slot and save the memory overhead of a hash table which will never be used.
