动态/静态/增量数据的专用哈希表算法

Question

我有许多具有键值模式的数据集 - 即字符串键和指向数据的指针。现在它存储在哈希表中，每个表都有对应于哈希键的槽数组，并且在发生冲突时在每个有冲突的槽下形成一个链表（直接链接）。如果重要的话，所有都在 C 中实现（并且应该保留在 C 中）。

现在，数据实际上是 3 种略有不同的数据集：

1. 可以随意更改某些集合（添加、删除、替换等）
2. 对于某些集合，可以添加数据，但几乎从不替换/删除（即可能发生，但在实践中非常罕见）
3. 对于某些集合，数据只添加一次，然后仅查找，一旦加载整个集合，它就永远不会更改。

当然，所有集合都必须尽可能快地支持查找，并且消耗最少的内存（尽管查找速度比大小更重要）。

所以问题是 - 是否有更好的哈希表结构/实现更适合特定情况？我怀疑对于第一种情况，链接是最好的，但不确定其他两种情况。

Answer 1

对存储在顺序内存中的键进行二分甚至线性搜索时，那些较小的集合（数十个元素）可能是最快的！

显然，密钥主体必须在顺序内存中，或者它们的散列中。但如果你能把它放到一两个 L1 cache.lines 中，它就会飞起来。

对于更大的哈希，直接链接可能会输给开放寻址？

您可以探索“cache conscious”哈希表并尝试。

wikipedia 文章详细讨论了缓存行，描述了要考虑的各种权衡。

Answer 2

如果您对哈希表中的每个存储桶都使用链表，那么您已经接受了现代 CPU 上相对较差的性能（链表的局部性较差，因此 CPU 缓存交互较差）。所以我可能不会担心优化其他特殊情况。但是，如果您想继续使用您正在使用的路径，这里有一些提示：

对于“频繁更改”数据集和“几乎从不更改”的情况，每次从哈希表中读取一个项目时，将其移动到该存储桶的链表链的前面。对于一些更好的想法，尽管这篇论文专注于固定大小的键，但它是一个很好的起点Fast and Compact Hash Tables for Integer Keys。

对于“数据集永远不会改变”的情况，您应该研究完美的哈希生成器。如果您在编译时知道您的密钥，我在gperf 上取得了很好的结果。如果您的密钥在运行时才可用，请尝试C Minimal Perfect Hashing Library。