假设我有200.000个单词，并且我将使用hash*33 + word[i]作为哈希函数，对于最小化内存/分页问题，优化表的大小应该是多少？
使用的平台 - C（c99版本），
单词是英文字符，ASCII值
哈希表的一次初始化（链接列表样式的桶），
用于搜索下一个，如字典搜索。
碰撞后，该单词将作为新节点添加到存储桶中。
答案 0 :(得分：9)
一个好的经验法则是将负载系数保持在75％或更低（有些人会说70％）以维持（非常接近）O（1）查找。 假设你有一个很好的哈希函数。
基于此，您需要至少约266,700个桶（75％）或285,700个桶（70％）。假设没有碰撞。
那就是说，你最好的办法是用各种哈希表大小的样本数据进行测试，看看你得到了多少次碰撞。
您可能还会考虑比hash*33 + word[i]更好的哈希函数。 Jenkins hash及其变体需要更多计算，但它们可以提供更好的分布，因此通常可以减少冲突并缩小所需的表格大小。
你也可以在这个问题上抛出记忆。表大小为500,000可以为您提供40％的最小加载因子，这可以弥补您的哈希函数的缺点。但是，你很快就会达到收益递减的程度。也就是说，使表格大小为100万，可以给出20％的理论载荷因子，但几乎可以肯定你实际上并没有意识到这一点。
长话短说：使用更好的哈希函数并在不同的表格大小上进行一些测试。
有minimal perfect hash之类的东西。如果您知道输入数据是什么（即它没有改变），那么您可以创建一个保证O（1）查找的哈希函数。它也非常节省空间。但是，我不知道为200,000个项目创建最小完美哈希是多么困难。