词典中的关键识别速度

Question

关于使用字符串作为键的任何词典的识别速度，我有一个相当普遍的问题，到目前为止找不到答案。

在我当前的程序中，我有一个自定义对象的字典，但我使用的密钥是文件名，包括文件的整个路径，这样任何密钥都不能实际出现两次。

我的问题是：在字典中找到特定对象的时间是否显着取决于用作密钥的字符串的长度？毕竟，如果我在对象中保存了大量数据，并且我在循环中使用该数据并使用myDictionary[Key]每次访问数据。简单识别可能需要很长时间，使循环持续较长时间。

我对这个问题的解决办法是：如果使用数组，我可以在我的对象中说double[,,]，我暂时创建一个新数组并将其设置为等于字典中的数组，所以我不要每次循环迭代时都必须在字典中搜索。

Answer 1

  

是否有时间在字典中查找特定对象   显着取决于用作键的字符串的长度？

是的。在字典中查找元素是通过两个CPU密集型步骤完成的：

1. 生成密钥的哈希码。
2. 相等地比较同一个存储桶中的所有元素。

字典将元素存储在存储桶中。为了能够进行O(1)查找，字典使用hashCode modulo array.Length计算内部数组中的位置。这可能导致元素具有相同的索引。这些元素存储在相同的索引下;这被称为桶。

对于字符串，使用字符串中的所有字符生成哈希码，这意味着字符串哈希码的生成具有O（n）的性能特征。当字符串很大时，生成哈希码需要更长的时间。通过比较两个字符串完全比较字符串是否相等。如果这些字符串包含，例如，100,000个字符，只有最后一个字符不同，比较两个字符串可能需要相当多的时间。如果它们与第一个字符不同，则比较将很快返回false。确定两个字符串实际上是相等的（如果它们不是引用相等）需要花费最多的时间，因为需要遍历完整的字符串。

如果可以，如果字典位于应用程序的性能关键路径中，则使密钥字符串变短。

Answer 2

修改
我的回答的措辞有点误导 - 试图清除它。

理论上，如果散列函数产生理想的散列码（意味着对于每个唯一输入，输出也是唯一的），在字典/散列表中查找应该是O（1）过程。如果两个输入字符串生成相同的哈希码（哈希函数不理想），则为该哈希码创建条目列表（“桶”），然后必须逐项搜索。

因此，一旦创建了哈希码，理论上查找存储桶就是O（1）操作。搜索存储桶是O（n）操作，其中n是存储桶中元素的数量。

字符串长度影响：

1. 创建哈希码。字符串越长，创建哈希码所需的时间就越长。
2. Bucket搜索：当逐项搜索存储桶时，字符串长度当然也很重要，因为它是搜索的关键。

所以：是，字符串长度实际上很重要。

真正的问题是，鉴于你说你经常迭代字典中的所有键，字典是否真的是你情况下的正确工具。在这种情况下，如果您很少插入但经常查找，则使用对象列表（包含文件名和其他数据）并通过在每次插入时查找文件名来防止插入重复项可能会更快。

Answer 3

通常，较短的字符串比较长的字符串表现更好。但是性能影响非常有限（直到你获得了数百万美元）。 您可以尝试微观工作台或阅读here