很明显,泛型HashSet<T>类的搜索性能要高于泛型List<T>类。只需将基于哈希的键与List<T>类中的线性方法进行比较。

然而,计算哈希键本身可能需要一些CPU周期,因此对于少量的项,线性搜索可以成为HashSet<T>的真正替代方法。

我的问题是:盈亏平衡在哪里?

为了简化场景(公平起见),让我们假设List<T>类使用元素的Equals()方法来标识一个项。


当前回答

视情况而定。如果确切的答案真的很重要,那就做一些分析,找出答案。如果你确定你永远不会有超过一定数量的元素在集合中,使用List。如果数字是无界的,则使用HashSet。

其他回答

视情况而定。如果确切的答案真的很重要,那就做一些分析,找出答案。如果你确定你永远不会有超过一定数量的元素在集合中,使用List。如果数字是无界的,则使用HashSet。

盈亏平衡将取决于计算散列的成本。哈希计算可以是微不足道的,或者不是…:-)总有System.Collections.Specialized.HybridDictionary类帮助你不必担心盈亏平衡点。

这取决于很多因素……列表实现,CPU架构,JVM,循环语义,equals方法的复杂性,等等…当列表变得足够大,可以有效地进行基准测试(1000多个元素)时,基于哈希的二进制查找就可以轻松地击败线性搜索,并且差异只会在此基础上扩大。

希望这能有所帮助!

您可以使用HybridDictionary自动检测断点,并接受空值,使其本质上与HashSet相同。

这取决于你在哈希什么。如果你的键是整数,在HashSet更快之前,你可能不需要很多项。如果你在一个字符串上输入键,那么它会更慢,这取决于输入的字符串。

你肯定可以很容易地建立一个基准吗?