【发布时间】：2010-12-05 02:22:15
【问题描述】：
我将在 .NET 项目中使用 Dictionary 来存储大量对象。因此我决定使用 GUID 字符串作为键，以确保每个对象的键都是唯一的。
诸如 GUID 之类的大键（甚至更大的键）是否会降低字典的性能，例如用于通过其键检索对象？
谢谢， 安德烈
【问题讨论】：
标签： c# performance dictionary
【发布时间】：2010-12-05 02:22:15
【问题描述】：
我建议使用实际的Guid 而不是Guid 的字符串表示。是的，在比较字符串时，长度确实会影响所需操作的数量，因为它必须逐个字符地比较字符串（至少；这禁止任何特殊选项，如 IgnoreCase）。实际的 Guid 将只给您 16 个字节进行比较，而不是 string 中的最小值 32。
话虽如此，您很可能不会注意到任何差异......过早的优化等等。我只会选择Guid 键，因为这就是数据。
【讨论】：
-
确实，散列一个 Guid 比散列一个 32 个字符的字符串要快得多。 +1
-
谢谢，这听起来很合理。
-
CLR 的字符串实习怎么样？ （内部创建的用于跟踪字符串的哈希表）
对象的实际大小与检索值无关。查找值的速度更多地取决于传入的IEqualityComparer<T> 实例上的两个方法的速度
- GetHashcode()
- 等于()
编辑
很多人都在使用 String 来证明较大的对象大小会降低查找性能。出于多种原因，必须对此持保留态度。
- 上述字符串方法的性能会随着默认比较器的字符串大小的增加而降低。仅仅因为 System.String 是正确的，并不意味着它一般是正确的
- 您可以轻松地编写一个不同的
IEqualityComparer<String>，使字符串长度无关紧要。
【讨论】：
-
您仍然必须首先遍历字符串来比较它，因此无论您的算法如何，大小都会影响性能。
-
@Blindy 不，你没有。这完全取决于我认为比较器中的相等字符串。也许我只关心前 3 个字母前缀？也许只有第一个字母。或者我只是说非空字符串是相等的。随着字符串变大，这些都不会改变大小
-
这似乎不适用于 OP，他需要对类似 guid 的键进行全面比较。
-
@Adam，我并不是要争论，但说字符串键大小对性能有直接影响是错误的。这可能是最有可能的默认情况，但它是一个不正确的断言。您根本无法查看 Dictionary 的 Key 类型并就查找的性能特征做出可靠的陈述。只有知道 IEqualityComparer
的详细信息才能为您提供此信息。 -
@Jared：是的，显然你是对的。你可以实现一个 O(1) 的
IEqualityComparer<T>（对于string或其他任何东西）。然而，这不太可能。您所做的区分是学术性的，我想会导致更多的混乱而不是增加清晰度。
是的，不是的。较大的字符串会增加字典的内存大小。更大的大小意味着计算哈希大小的时间稍长。
但担心这些事情可能是过早的优化。虽然速度会慢一些，但您可能不会真正注意到。
【讨论】：
显然是这样。这是一个很好的测试：Dictionary String Key Test
【讨论】：
-
不是一个很好的测试，因为它显示在比较 2 个和 20 个字符键时，1 亿次字典查找的性能提升仅为 3 秒。在字典的大多数使用中，这并不是一个显着的收获。
-
2 个字符：1.5 秒。 20 个字符：4.5 秒。由于这 3 秒相当于提高了 3 倍，我认为这很重要。当然，只要字典查找是您处理过程中最慢的一步。
【讨论】：
-
这并不是一个真正好的测试，因为在比较 2 和 20 个字符键时，它显示 1 亿次字典查找的性能提升仅为 3 秒。在字典的大多数使用中，这并不是一个显着的收获。在我能找到的字典的每一个现实世界使用中，性能提升将以纳秒为单位。因此，您的说法“通常较短的键比较长的键执行得更好”具有误导性。 “一般”，微不足道。
请参阅Performance - using Guid object or Guid string as Key 了解类似问题。您可以使用备用密钥对其进行测试。
【讨论】：