“嵌套 foreach”与“lambda/linq 查询”性能（LINQ 到对象）[关闭]

从性能角度来看，您应该使用“嵌套 foreach”或“lambda/linq 查询”？

尽可能编写最清晰的代码，然后进行基准测试和分析以发现任何性能问题。如果你do遇到性能问题时，您可以尝试不同的代码来确定它是否更快（始终使用尽可能真实的数据进行测量），然后做出判断，确定性能的改进是否值得牺牲可读性。

直接一个foreach方法will在许多情况下比 LINQ 更快。例如，考虑：

var query = from element in list
            where element.X > 2
            where element.Y < 2
            select element.X + element.Y;

foreach (var value in query)
{
    Console.WriteLine(value);
}

现在有两个where条款和一个select子句，因此每个最终项都必须经过三个迭代器。 （显然，在这种情况下可以组合两个 where 子句，但我提出的是一般性观点。）

现在将其与直接代码进行比较：

foreach (var element in list)
{
    if (element.X > 2 && element.Y < 2)
    {
        Console.WriteLine(element.X + element.Y);
    }
}

这样会跑得更快，因为它需要穿过的圈更少。不过，控制台输出很可能会使迭代器成本相形见绌，而且我当然更喜欢 LINQ 查询。

编辑：要回答“嵌套 foreach”循环...通常用SelectMany或第二个from clause:

var query = from item in firstSequence
            from nestedItem in item.NestedItems
            select item.BaseCount + nestedItem.NestedCount;

这里我们只添加一个额外的迭代器，因为由于嵌套，我们已经在第一个序列中的每个项目使用了一个额外的迭代器foreach环形。仍然有一些开销，包括在委托中而不是“内联”（我之前没有提到的东西）中进行投影的开销，但它仍然不会与嵌套 foreach 性能有太大不同。

当然，这并不是说您不能使用 LINQ 搬起石头砸自己的脚。如果您不首先动动脑筋，您可能会编写出极其低效的查询 - 但这远非 LINQ 所独有...