我有一个类，像这样:

public class MyClass
{
    public int Value { get; set; }
    public bool IsValid { get; set; }
}

_{实际上它要大得多，但这会重现问题(奇怪)。}

我想得到 Value 的总和，其中实例有效。到目前为止，我已经找到了两种解决方案。

第一个是这样的:

int result = myCollection.Where(mc => mc.IsValid).Select(mc => mc.Value).Sum();

然而，第二个是这样的:

int result = myCollection.Select(mc => mc.IsValid ? mc.Value : 0).Sum();

我想获得最有效的方法。起初，我认为第二个会更有效率。然后我的理论部分开始“好吧，一个是 O(n + m + m)，另一个是 O(n + n)。第一个应该在更多无效的情况下表现更好，而第二个应该表现更好用更少”。我以为他们会表现得一样。 编辑:然后@Martin 指出 Where 和 Select 结合在一起，所以它实际上应该是 O(m + n)。但是，如果您往下看，这似乎与此无关。

So I put it to the test.

_{(超过 100 行，所以我认为最好将其作为 Gist 发布。)}
结果……很有趣。

_{领带公差为 0%:}

天平有利于 Select和 Where , 大约 30 点。

How much do you want to be the disambiguation percentage?<br/> 0<br/> Starting benchmarking.<br/> Ties: 0<br/> Where + Select: 65<br/> Select: 36<br/>

_{2% 领带公差:}

除了一些误差在 2% 以内外，两者都是一样的。我会说这是最小误差范围。 Select和 Where现在只有大约 20 分的领先优势。

How much do you want to be the disambiguation percentage?<br/> 2<br/> Starting benchmarking.<br/> Ties: 6<br/> Where + Select: 58<br/> Select: 37<br/>

_{5% 领带公差:}

这就是我所说的最大误差范围。它使 Select 变得更好一点, 但不多。

How much do you want to be the disambiguation percentage?<br/> 5<br/> Starting benchmarking.<br/> Ties: 17<br/> Where + Select: 53<br/> Select: 31<br/>

_{10% 领带公差:}

这超出了我的误差范围，但我仍然对结果感兴趣。因为它给出了 Select和 Where它已经有一段时间领先 20 分了。

How much do you want to be the disambiguation percentage?<br/> 10<br/> Starting benchmarking.<br/> Ties: 36<br/> Where + Select: 44<br/> Select: 21<br/>

_{25% 领带公差:}

这超出了我的误差范围，方式，但我仍然对结果感兴趣，因为 Select和 Where 仍然(几乎)保持他们 20 分的领先优势。它似乎在少数几个方面超越了它，这就是它领先的原因。

How much do you want to be the disambiguation percentage?<br/> 25<br/> Starting benchmarking.<br/> Ties: 85<br/> Where + Select: 16<br/> Select: 0<br/>

现在，我猜测 20 分的领先优势来自中间位置，他们肯定会在附近获得相同的表现。我可以尝试记录它，但要吸收大量信息。我想图表会更好。

这就是我所做的。

它表明 Select线保持稳定(预期)并且 Select + Where线路攀升(预期)。然而，令我困惑的是为什么它不符合 Select在 50 或更早:事实上我期望早于 50，因为必须为 Select 创建一个额外的枚举器和 Where .我的意思是，这显示了 20 分的领先优势，但并没有解释原因。我想这就是我的问题的要点。

为什么会这样？我应该相信它吗？如果没有，我应该使用另一个还是这个？

正如@KingKong 在评论中提到的，您还可以使用 Sum需要 lambda 的重载。所以我的两个选项现在变成了这样:

首先:

int result = myCollection.Where(mc => mc.IsValid).Sum(mc => mc.Value);

第二个:

int result = myCollection.Sum(mc => mc.IsValid ? mc.Value : 0);

我打算让它更短一些，但是:

How much do you want to be the disambiguation percentage?<br/> 0<br/> Starting benchmarking.<br/> Ties: 0<br/> Where: 60<br/> Sum: 41<br/> How much do you want to be the disambiguation percentage?<br/> 2<br/> Starting benchmarking.<br/> Ties: 8<br/> Where: 55<br/> Sum: 38<br/> How much do you want to be the disambiguation percentage?<br/> 5<br/> Starting benchmarking.<br/> Ties: 21<br/> Where: 49<br/> Sum: 31<br/> How much do you want to be the disambiguation percentage?<br/> 10<br/> Starting benchmarking.<br/> Ties: 39<br/> Where: 41<br/> Sum: 21<br/> How much do you want to be the disambiguation percentage?<br/> 25<br/> Starting benchmarking.<br/> Ties: 85<br/> Where: 16<br/> Sum: 0<br/>

20 分的领先优势仍然存在，这意味着它与 Where 无关和 Select @Marcin 在评论中指出的组合。

_{感谢您阅读我的文字墙!另外，如果您有兴趣，here's记录 Excel 接收的 CSV 的修改版本。}

最佳答案

Select 在整个集合上迭代一次，并为每个项目执行条件分支(检查有效性)和 + 操作。

Where+Select 创建一个跳过无效元素的迭代器(不会 yield 它们)，仅对有效元素执行 + .

因此，Select 的成本是:

t(s) = n * ( cost(check valid) + cost(+) )

对于Where+Select:

t(ws) = n * ( cost(check valid) + p(valid) * (cost(yield) + cost(+)) )

地点:

• p(valid) 是列表中某项有效的概率。
• cost(check valid)是检查有效性的分支的成本
• cost(yield) 是where 迭代器构造新状态的代价，它比Select版本使用。

如您所见，对于给定的 n，Select 版本是常数，而 Where+Select 版本是线性的以 p(valid) 作为变量的等式。成本的实际值决定了两条线的交点，由于 cost(yield) 可以不同于 cost(+)，因此它们不一定相交在 p(有效)=0.5。

关于c# - 为什么 Where 和 Select 的表现优于 Select？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18331774/