关于使用字符串作为键的任何字典的识别速度，我有一个相当普遍的问题，到目前为止找不到答案。
在我当前的程序中，我有一个自定义对象的字典，但我使用的键是文件名，包括文件的整个路径，因此实际上没有键可以出现两次。
我的问题是：在字典中查找特定对象的时间是否很大程度上取决于用作键的字符串的长度？毕竟，如果我在我的对象中保存了大量数据，并且我在循环中使用这些数据并每次使用myDictionary[Key]. 简单的识别可能需要很长时间，从而使循环持续更长的时间。
我对这个问题的解决方案是：如果使用数组，假设double[,,]在我的对象中，我临时创建一个新数组并将这个数组设置为等于字典中的数组，所以我不必搜索字典对于每一个循环迭代。
在字典中查找特定对象的时间是否很大程度上取决于用作键的字符串的长度？
是的，它确实。在字典中查找元素需要两个 CPU 密集型步骤：
字典将元素存储在桶中。为了能够进行O(1)查找，字典使用 计算内部数组中的位置hashCode modulo array.Length。这可能导致元素具有相同的索引。这些元素存储在同一个索引下；这被称为桶。
对于一个字符串，哈希码是使用字符串中的所有字符生成的，这意味着该字符串的哈希码的生成具有O(n)的性能特征。当字符串很大时，生成哈希码需要更长的时间。通过完全比较两个字符串来比较字符串是否相等。如果这些字符串包含 100,000 个字符并且只有最后一个字符不同，那么比较这两个字符串可能会花费大量时间。如果它们与第一个字符不同，则比较将很快返回 false。确定两个字符串实际上相等（如果它们不是引用相等）需要最多时间，因为需要遍历完整的字符串。
如果可以，如果字典位于应用程序的性能关键路径中，请缩短键字符串。
编辑
我的回答措辞有点误导 - 试图澄清这一点。
理论上，如果哈希函数产生理想的哈希码（意味着对于每个唯一输入，输出也是唯一的），那么在字典/哈希表中查找应该是一个 O(1) 过程。如果两个输入字符串生成相同的散列码（散列函数不理想），则为该散列码创建一个条目列表（“桶”），然后必须逐项搜索。
因此，一旦创建了哈希码，理论上查找存储桶是一个 O(1) 操作。搜索桶是一个 O(n) 操作，其中 n 是桶中元素的数量。
字符串长度影响：
所以：是的，字符串长度确实很重要。
真正的问题是字典是否真的是适合您情况的工具，因为您说您经常迭代字典中的所有键。在这种情况下，如果您很少插入但经常查找，则使用对象列表（包含文件名和其他数据）并通过在每次插入时查找文件名来防止插入重复项可能会更快。
通常，较短的字符串比较长的字符串执行得更好。但是对性能的影响是非常有限的（直到你有百万个 get）。你可以试试微型长凳或在这里阅读