Performance 哈希表中的链接

当我们有一个带有链接的哈希表时：

---

我只是想知道，按顺序维护每个键的列表是否会影响哈希表中搜索、插入和删除的运行时间？

当然可以。通常为哈希表引用的O（1）是假设完全哈希，即没有两个不相同的项解析为同一个哈希

实际上，情况并非如此。对于足够大的数据集，您将始终存在冲突。而冲突将意味着在查找时需要更多的工作，无论您是使用链接还是其他冲突解决技术

---

这就是为什么选择一个设计/编写良好的好的散列函数非常重要，并且与将用作散列表键的数据匹配良好。在实践中，不同类型的数据使用不同的散列函数会更好地进行散列。

假设您已经选择了散列算法和映射大小，以减少首先会遇到的冲突数量。在这一点上，您应该在任何位置都有一个非常小的列表（理想情况下是一个或两个元素），因此在链中维护排序结构的额外工作肯定不仅仅是迭代该存储桶中的少量项目。

理论上：是，因为在一般情况下，你只需要走一半的链条就可以找到一件物品是否在链条上

在实践中，可能没有太大区别，因为链通常很短，而且增加的代码复杂性也会花费一些周期，主要是在“插入”情况下

顺便说一句：在大多数情况下，插槽的数量远远小于散列值的“键空间”。如果您能提供足够的空间，那么在链节点中存储哈希值将节省在每个跃点上重新计算哈希值的时间，并将避免大多数最终比较。这当然是一种时空权衡。例如：

struct hashnode **this;
for (this=& table[slot] ; *this; this = &(*this)->link) {
    if ((*this)->hash != the_hash) continue;
    if (compare ((*this)->payload , the_value)) continue;
    break;
 }
 /* at this point "this" points to the pointer that points to the wanted element,
    or to the NULL-pointer where it should be inserted.

    For the sorted-list example, you should instead break out of the loop
    if the compare function returns > 0, and handle that special case here.

 */

---

你的意思是像地图一样吗？@user1291492我想他的意思更像这样：这不是他问的问题。他特别问，一旦发生冲突，他应该做什么——他应该对列表进行索引或排序，如果他这样做，复杂性问题会是什么？