LINQ 比简单循环慢得多吗？ [复制]

Question

可能重复：
Should LINQ be avoided because it's slow?

我喜欢 LINQ。正如我今天在另一篇文章中读到的“这是自切片面包以来最好的事情”，我完全同意。但在我工作的公司里，其他人似乎都讨厌 LINQ。

几周前，我第一次使用 ReSharper，在编写代码时，ReSharper 突然告诉我，我的 foreach 循环可以转换为 LINQ 表达式。这对我来说就像魔术一样，我向我的同事展示了。令我惊讶的是，他说：“我希望它能够反过来工作并将 LINQ 变成循环。这样会快很多！”

那么 LINQ-to-Objects 真的那么慢吗？我自己试了一下。 当我运行以下示例几次时，我得到大约 350 的 Elapsed Ticks。

        Stopwatch sw = new Stopwatch();

        List<Person> personList = new List<Person>();
        for (int i = 0; i < 5000; i++)
        {
            Person p = new Person() {ID = i};
            personList.Add(p);
        }

        sw.Start();

        Person searchPerson = null;

        foreach (Person person in personList)
        {
            if (person.ID == 4321)
            {
                searchPerson = person;
                break;
            }
        }

        sw.Stop();

        Console.WriteLine(sw.ElapsedTicks);

如果我将循环更改为 LINQ 查询（Resharper 会为我执行此操作），我会得到大约 900 的 ElapsedTicks。是循环的两倍多。

Person searchPerson = personList.FirstOrDefault(person => person.ID == 4321);

目前看来 LINQ 确实较慢，如果您经常使用它，这可能是个问题。在我们公司，我们拥有大量数据。那么，避免 LINQ 是正确的决定还是我们做错了什么？

Answer 1

是的，它更慢。但是，该延迟的一部分是一次性初始化延迟，而不是每次迭代延迟。在 10 万次迭代循环中，百分比差异要小得多。

要带走的一点是，开发人员的时间比代码中的小幅性能损失要贵得多，除非客户打电话给你抱怨性能问题。编写可读且可维护的代码远比微优化代码更重要。

正如 Eric Lippert 完美指出的那样，LINQ should only be avoided if it's not fast enough。