“嵌套foreach"vs “lambda/linq 查询"性能(LINQ 到对象) [英] "Nested foreach" vs "lambda/linq query" performance(LINQ-to-Objects)

问题描述

从性能的角度来看，您应该使用嵌套 foreach"还是lambda/linq 查询"?

In performance point of view what should you use "Nested foreach's" or "lambda/linq queries"?

推荐答案

尽可能编写最清晰的代码，然后进行基准测试和分析以发现任何性能问题.如果您确实遇到性能问题，您可以尝试不同的代码来确定它是否更快(始终使用尽可能真实的数据进行测量)，然后判断是否性能的提升值得提高可读性.

Write the clearest code you can, and then benchmark and profile to discover any performance problems. If you do have performance problems, you can experiment with different code to work out whether it's faster or not (measuring all the time with as realistic data as possible) and then make a judgement call as to whether the improvement in performance is worth the readability hit.

在许多情况下，直接foreach 方法将比 LINQ 更快.例如，考虑:

A direct foreach approach will be faster than LINQ in many cases. For example, consider:

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 子句结合起来，但我是在提出一般观点.)

Now there are two where clauses and a select clause, so every eventual item has to pass through three iterators. (Obviously the two where clauses could be combined in this case, but I'm making a general point.)

现在与直接代码进行比较:

Now compare it with the direct code:

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

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

That will run faster, because it has fewer hoops to run through. Chances are that the console output will dwarf the iterator cost though, and I'd certainly prefer the LINQ query.

要回答有关嵌套 foreach"循环的问题...通常用 SelectMany 或第二个 from 子句表示:

To answer about "nested foreach" loops... typically those are represented with SelectMany or a second from clause:

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

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

Here we're only adding a single extra iterator, because we'd already be using an extra iterator per item in the first sequence due to the nested foreach loop. There's still a bit of overhead, including the overhead of doing the projection in a delegate instead of "inline" (something I didn't mention before) but it still won't be very different to the nested-foreach performance.

当然，这并不是说你不能用 LINQ 用脚射击自己.如果您不先动脑筋，您可能会编写非常低效的查询 - 但这远非 LINQ 独有...

This is not to say you can't shoot yourself in the foot with LINQ, of course. You can write stupendously inefficient queries if you don't engage your brain first - but that's far from unique to LINQ...

这篇关于“嵌套foreach"vs “lambda/linq 查询"性能(LINQ 到对象)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！