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

Question

因此，在计算哈希表的加载因子时是否应该包含逻辑删除的问题出现了。

我认为，鉴于负载系数用于确定何时扩展容量，不应包括逻辑删除。一个明显的例子是你几乎填充然后删除哈希表中的每个值。插入非常容易（没有碰撞），所以我认为负载因子不应该包含它们。

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

所以我想我会问这个问题。哈希表的加载因子是否应包含计算中的逻辑删除？

Answer 1

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

此外，在我看来，在95％的现代哈希表案例中，这种方式过于简化，动态系统表现不佳。它的优点是：

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

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

<小时/> 如果您使用墓碑开发通用哈希表，我认为您可以获取我的结果（如下）。我花了几周时间专门开发这个模型。也许你可以做一些改进或进一步研究，我很高兴。

目标是两个主要哈希表动态行为模式：

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

定义了两个阈值：

• max size （即活着的条目数），table size * max load

• 最小免费数量（即空，无活动条目或墓碑）插槽，computed by magic formula。

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

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

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

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

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