How is the size of hash table determined?

It sounds like you have a general idea about the characteristics of data you're going to be storing in your hash table. Given this information, if you want to optimize for this data set, you should write your program using different sizes for the hash table, time the implementations, and pick the fastest one. You have a large-ish data set, so maybe start testing in intervals of a couple thousand. You should get a nice inverse-bell curve. Find the data point that's lowest on that graph (lower time = better performance) and "zoom in" on that region, using smaller intervals of a couple hundred to find the optimal value.

If the data amount you are going to store is static (i.e. Always consistent in every execution), it is good by directly allocating array for your hashtable as many rows as you need. It will save the execution time by avoiding reallocation/rehash But if the data amount is in growing manner, you should allocate it on demand in order to save memory. You can start by having 1024 rows, then when it reach third quarter of its size, the hashtable size quadrupled to 4096 and so on. If you want to employ multithreading, you can also make the execution of rehash/reallocating the hashtable in different thread. It is just an idea though, but for an implementation, never really try it. I think it will be painful.

It's a tuning parameter - it depends what you're trying to optimize and what resources you have or are willing to commit but thinking performance will be proportional to average collision chain length is the right thing to be managing.   I don't know what your application is but assuming you optimize collision handling 3-4 chains will be blisteringly fast on any modern laptop (up). If you're on a phone or smaller device you might find this is more of a size/speed trade-off. It's a common myth for this kind of hash-table that you should pick a prime number but because your hash value has a tendency to have a fixed remainder modulo 33 you should pick something co-prime with 33.   A smart choice is a power of 2. That's because you can obtain the remainder by masking bits with & and avoid a (relatively) costly / implicit in your %. NB: A side-effect of using powers of 2 is that it's easy to divide or combine collision chains if you resize the table dynamically. However I get the impression you have a static dictionary and won't be re-sizing. Optimized? First, make sure you retain the full hash (an unsigned 32-bit int will be likely suitable). Second when traversing a collision chain compare hash before value. If the hashes don't match you don't need a (relatively) expensive string comparison.  The hash you've chosen is known to have good performance with English text you should find few if any collisions at full 32-bit hash comparison and make next to zero failed string comparisons. Third consider ordering the collision chain. If access is random order it by hash value. That way you can dive out of a chain when you realize the look-up value can't be held. Alternatively if access isn't random consider ordering the collision chains by a static or dynamic frequency. Static frequency would be based on occurrence of a word in some text "corpus". That is you'd want 'the' to appear at the front of its collision chain and 'wayzgoose' likely towards the end! Dynamic frequency would involve moving words that are 'hit' to the front of their collision chain knowing words recur in a given text.  If you are writing a spell checker (and I've somewhat assumed that's the application)  I really do recommend finding a corpus. It doesn't even have to be very big because (of course) the common words are common and will sort to the front very quickly and even if the 'uncommon' words aren't optimized - they have less impact because they're uncommon! PS: I also know a practically perfect (in the formal sense) hash for English words however I think you'll find your hash is pretty good.