使用单独的链接并用已知数量的N个条目初始化的，固定大小的哈希表中最佳存储桶数量是多少？

如何解决使用单独的链接并用已知数量的N个条目初始化的，固定大小的哈希表中最佳存储桶数量是多少？

HT不重新哈希。 我们使用一种简单的除法作为哈希函数。 我们假设哈希函数可以有效地平均分配条目。 目的是让O（1）插入，删除和查找。

解决方法

对于预期的使用模式，最佳存储桶数是内存消耗和哈希冲突之间的折衷。

例如，如果使用频率很高，则可以将哈希表的大小限制为CPU缓存的一半，以减少“缓存未命中访问哈希表”的机会；这可能比使用更大的哈希表更快（缓存未命中率更高，哈希冲突的可能性更低）。或者如果不经常使用它（因此，无论哈希表大小如何，您都希望缓存未命中），那么更大的大小更可能是最佳选择。

当然，实际系统具有多个高速缓存（L1，L2，L3）以及虚拟内存转换高速缓存（TLB）加上RAM限制（加上交换空间限制）；真正的软件具有不止一个哈希表竞争内存层次结构中的资源；通常，软件开发人员不知道可能正在运行其他哪些进程（竞争物理RAM，污染高速缓存等）或任何最终用户的硬件（高速缓存的大小等）。所有这一切几乎使得用任何方法（包括广泛的基准测试）都无法确定“最佳”。

唯一可行的选择是根据各种假设进行有根据的猜测（关于使用情况，数据量以及哈希函数在实践中的性能，CPU，其他可能使用CPU和内存的事物， ...）;并使源代码可配置（例如#define HASH_TABLE_SIZE ..），以便稍后可以轻松地重新评估猜测。