带有墓碑的哈希表的负载因子

Question

所以问题来了，在计算哈希表的负载因子时是否应该包括墓碑。

我认为，鉴于负载因子用于确定何时扩展容量，墓碑不应该包括在内。一个明显的例子是，如果您几乎填充然后删除哈希表中的每个值。这里的插入非常容易（没有冲突），所以我认为负载因子不应该包括它们。

但是你可以看看这个并认为所有的墓碑查找都会很慢（可能搜索几乎整个空间）。

所以我想我会问这个问题。哈希表的负载因子是否应该在计算中包括墓碑？

Answer 1

负载因子不是哈希表数据结构的重要组成部分——它是为动态系统定义行为规则的方式（增长/收缩哈希表是一个动态系统）。

此外，在我看来，在 95% 的现代哈希表案例中，这种方式过于简化，动态系统的行为并不理想。它的优点：

• 嗯，理解和实现很简单。
• 哈希表数据结构不应存储具有某些阈值的多个数字——可能只存储一个数字。当哈希表非常小时并且标头的大小会影响整个数据结构的内存效率（以字节为单位来存储条目）时，这很有意义。
• 在某些（和常见）情况下：仅追加/更新哈希表，更复杂的行为模型退化为“仅加载因子”模型，换句话说，加载因子模型定义了相对最优的行为。

See also my answer on load factor model. I prefer [min load, target load, max load] + growth factor frame model.

---

如果你用墓碑开发通用哈希表，我想你可以拿起我的结果（下）。我可能会花费数周时间单独开发此模型。也许您可以进行一些改进或进一步研究，我会很高兴。

针对两种主要的哈希表动态行为模式：

• 增长的哈希表（可能处于增长阶段），几乎没有删除
  • 哈希表的初始填充，当未指定（或未知）适当容量时
• 保持相同或几乎相同大小的哈希表，删除次数等于或几乎等于插入次数
  • 具有上限的缓存、LRU、条目过期的表

定义了两个阈值：

• 最大尺寸（即活动条目数），table size * max load

• 空闲（即空，没有活动条目或墓碑）槽的最小数量，computed by magic formula。

如果哈希表大小超过最大大小，我们假设我们处于“增长模式”，重新哈希表大小以便能够存储current size * growth factor 条目，即。 e.选择最接近current size * growth factor / target load 的表格大小。

如果空闲槽的数量低于空闲槽的最小数量，我们处于“缓存模式”，重新哈希“到当前大小”，即。 e.最接近current size / target load 的表格大小。

阅读the source where all the above logics are coded。

另外，Tombstones purge from hashtable: theory and practice 文章也提供了一些启示。

---

如果您开发专门用途的哈希表，其中动态属性是已知的（或可以研究），我建议您开发适合您情况的自己的模型。不要依赖纯数学和 CS 理论，在基准测试中评估您的模型。