Hash tables should be sized with prime numbers. The current algorithm
of growth (2*n + 1) is better than the old 2*n, but still deficient.
Starting with the default hash table size, there are eight numbers in
the sequence before the next prime. (2*n - 1) would be a *bit*
better.

But there is no need to do either. Included in the Suggested Fix is
some code that looks for the next prime above a certain number in a
fairly brute force fashion. It has been tested on all values up to
10,000 and works. The largest number of modulo operations in that
sequence was 144 for 9977. Considering this would happen right before
approximately 7500 modulos when rehashing the contents of the table
(assuming a 75% load factor for the table), this seems a pretty small
price to pay to make those 7500 modulos *effective*.

Faster mechanisms could easily be developed, but this is the one I
did. If you simply take it, the hash table will perform better in many
cases, and worse in *very* few (only those cases where the user-provided
size is a value like 9977 and very few insertions take place, and none
of those insertions are hurt by the original non-primen-ess of the
table size).