扫描文件以查找 HashTable 大小的确切大小与不断调整数组大小和 ReHashing 等问题答案

【问题标题】：Scanning File to find exact size of HashTable size vs constantly resizing Array and ReHashing and other questions扫描文件以查找 HashTable 大小的确切大小与不断调整数组大小和 ReHashing 等问题
【发布时间】：2014-04-02 05:32:09
【问题描述】：

所以我正在做一个项目，这需要我找到给定文件中的所有字谜。每个文件的每一行都有单词。

到目前为止我做了什么：

1.) 对单词进行排序（使用 Mergesort -（我认为这是最坏情况下最好的......对吗？）） 2.) 使用散列函数放入散列表 3.）如果发生冲突，则移动到数组中的下一个可用空间（基本上一个接一个地下降，直到您在哈希表中看到一个空白点）（有没有更好的方法呢？我在线性做什么试探）。

问题：

当哈希表中的空间用完时.. 我该怎么办？我想出了两个解决方案，要么在将任何内容输入哈希表之前扫描文件并具有一个精确的大小，要么不断调整数组的大小并随着它变得越来越满而重新散列。我不知道该选择哪一个。任何提示都会有所帮助。

【问题讨论】：

标签： arrays hashtable

【解决方案1】：

一些建议：

排序通常是一个好主意，我可以想办法在这里使用它，但是如果您之后所做的只是将项目放入哈希表中，那么排序就没有任何优势。哈希表是为恒定时间插入而设计的，即使插入项的顺序没有特定顺序。
Mergesort 是几种最坏情况复杂度为 O(nlog n) 的排序算法之一，如果您所能做的就是比较两个元素以确定哪个更小，这是最佳的。如果您可以执行其他操作，例如索引数组，则可以使用 radixsort 完成 O(n) 排序 - 但几乎可以肯定不值得您花时间研究这个（尤其是因为您甚至可能根本不需要排序）。
如果在哈希表已满时将其大小调整为常量因子（例如将大小增加一倍或三倍），那么您将保持恒定时间插入。（如果您按一个常数 amount 调整大小，您的插入将降级为每次插入的线性时间，或所有 n 次插入的二次时间。）这可能看起来很浪费内存，但如果您的调整大小因子为 k，那么浪费空间的比例永远不会超过（k-1）/k（例如加倍为50％）。因此，预先计算确切大小永远不会有任何渐近执行时间优势，尽管这可能是更快（或更慢）的某个常数因素。
有多种方法可以处理哈希冲突，它们以不同的方式权衡执行时间与最大可用密度。

【讨论】：