在散列表或排序列表中找到项目哪个更快？
答案 0 :(得分：27)
算法复杂度是一件好事，并且哈希表已知为 O（1）而有序向量（在您的情况下我认为使用排序数组比列表更好）将提供 O（log n）访问时间。
但是你应该知道，复杂符号可以让你获得N进入无限的访问时间。这意味着，如果您知道数据将继续增长，复杂符号会为您提供一些选择的算法提示。
当您知道数据的长度相当低时：例如，您的数组/哈希表中只有少量条目，您必须使用手表并进行测量。所以进行测试。
例如，在另一个问题中：对数组进行排序。对于一些条目冒泡排序，而 O（N ^ 2）可能比快速排序更快，而它是 O（n log n）< / em>的
此外，相应于其他答案，并且根据您的项目，您必须尝试为哈希表实例找到最佳哈希函数。否则，它可能会导致哈希表中查找的显着不良性能（正如Hank Gay的答案所指出的那样）。
修改：看看这篇文章，了解the meaning of Big O notation 。
答案 1 :(得分：13)
假设“排序列表”是指“随机可访问，已排序的集合”。列表具有只能逐个元素遍历的属性，这将导致O（N）复杂性。
在排序的可索引集合中查找元素的最快方法是通过N-ary搜索，O（logN），而没有collissions的哈希表的查找复杂度为O（1）。
答案 2 :(得分：7)
除非哈希算法非常慢（和/或差），否则哈希表会更快。
更新：正如评论者指出的那样，你也可能因太多的冲突而降低性能，不是因为你的哈希算法很糟糕，而是因为哈希表不够大。大多数库实现（至少在高级语言中）将在幕后自动增加哈希表 - 这将导致插件上的性能低于预期，从而触发增长 - 但如果你自己滚动，那肯定是考虑。
答案 3 :(得分：5)
get中的SortedList操作为O(log n)，而与HashTable相同的操作为O(1)。所以，通常，HashTable会更快。但这取决于许多因素：
答案 4 :(得分：3)
完全取决于您存储的数据量。
假设你有足够的内存可以抛出它（所以哈希表足够大），哈希表会在固定的时间内找到目标数据，但是计算哈希的需要会增加一些（也是固定的）开销。
搜索已排序的列表不会产生散列开销，但实际定位目标数据所需的时间会随着列表的增长而增加。
因此，通常，对于小型数据集，排序列表通常会更快。 （对于频繁更改和/或不经常搜索的极小数据集， un 排序列表可能更快，因为它避免了进行排序的开销。）随着数据集变大，列表搜索时间的增长掩盖了哈希的固定开销，哈希表变得更快。
该断点的位置将根据您的特定哈希表和sorted-list-search实现而有所不同。在许多通常大小的数据集上运行测试和基准测试性能，以查看哪些在您的特定情况下实际上会更好。 （或者，如果代码已经“足够快”运行，请不要。只需使用您感觉更舒服的东西，不要担心优化不需要优化的东西。）
答案 5 :(得分：1)
在某些情况下，它取决于集合的大小（在较小程度上，实现细节）。如果你的名单非常小，可能有5-10项，我猜这个名单会更快。否则xtofl没错。
答案 6 :(得分：0)
对于包含10个以上项目的列表，HashTable会更有效。如果列表少于10个项目，则由于哈希算法导致的开销将更多。
如果您需要快速字典但需要以有序方式保留项目，请使用OrderedDictionary。 （.Net 2.0起）