如何克服从 IEnumerable<T> 创建 List<T> 的开销？

Question

我正在使用一些 LINQ 选择内容来创建一些集合，这些集合返回 IEnumerable<T>。

就我而言，我需要一个List<T>，所以我将结果传递给List<T> 的构造函数来创建一个。

我想知道这样做的开销。我收藏的物品通常以数百万计，所以我需要考虑这一点。

我假设，如果IEnumerable<T> 包含ValueTypes，这是最差的性能。

我说的对吗？ Ref 类型呢？无论哪种方式，都需要调用List<T>.Add 一百万次的成本，对吧？

有什么办法解决这个问题吗？就像我可以使用扩展方法“重载” LINQ Select 这样的方法吗？

Answer 1

不，如果您使用的是IEnumerable<T> 而不是IEnumerable，则元素类型是值类型并没有特别的惩罚。你不会参加任何拳击比赛。

如果您实际上事先知道结果的大小（Select 的结果可能不会），您可能需要考虑创建具有该缓冲区大小的列表，然后使用 @ 987654325@ 添加值。否则，列表每次填充时都必须调整其缓冲区的大小。

例如，而不是做：

Foo[] foo = new Foo[100];
IEnumerable<string> query = foo.Select(foo => foo.Name);
List<string> queryList = new List<string>(query);

你可能会这样做：

Foo[] foo = new Foo[100];
IEnumerable<string> query = foo.Select(x => x.Name);
List<string> queryList = new List<string>(foo.Length);
queryList.AddRange(query);

您知道调用Select 将产生与原始查询源长度相同的序列，但据我所知，执行环境中没有任何信息。 p>

Answer 2

最好避免需要列表。如果你可以让你的调用者使用 IEnumerable，你会省去一些麻烦。

LINQ 的 ToList() 将获取您的枚举，并使用 List(IEnumerable) 构造函数直接从中构造一个新的 List。这与自己制作列表一样，在性能方面（尽管 LINQ 也会进行空值检查）。

如果您自己添加元素，请使用 AddRange 方法而不是 Add。 ToList() 与 AddRange 非常相似（因为它使用采用 IEnumerable 的构造函数），在这种情况下，这通常是您最好的选择，性能方面。

Answer 3

一般来说，返回IEnumerable 的方法不必在实际需要项目之前评估任何项目。因此，理论上，当您返回 IEnumerable 时，此时您不需要存在任何项目。

因此，创建列表意味着您确实需要评估项目，获取它们并将它们放置在内存中的某个位置（至少是它们的引用）。对此无能为力 - 如果您真的需要一份清单。

Answer 4

许多其他响应者已经提供了有关如何提高将 IEnumerable<T> 复制到 List<T> 的性能的想法 - 我认为在这方面可以添加的内容不多。

但是，根据您所描述的内容，您需要对结果进行处理，以及您在完成后摆脱列表的事实（我认为这意味着中间结果并不有趣） - 您可能想考虑你是否真的需要实现一个List<T>。

与其创建List<T> 并对该列表的内容进行操作，不如考虑为IEnumerable<T> 编写一个执行相同处理逻辑的惰性扩展方法。我自己在很多情况下都这样做过，在使用编译器支持的[yield return][1] 语法时，用 C# 编写这样的逻辑还不错。

如果您想要做的只是访问结果中的每个项目并从中收集一些信息，那么这种方法很有效。通常，您需要做的只是按需访问集合中的每个元素，对其进行一些处理，然后继续。这种方法通常比创建集合的副本来迭代它更具可扩展性和性能。

现在，由于其他原因，此建议可能对您不起作用，但值得考虑作为寻找最有效方法来实现非常大的列表的替代方法。

Answer 5

不要将 IEnumerable 传递给 List 构造函数。 IEnumerable 有一个 ToList() 方法，它不可能做得比这更糟，而且语法更好（恕我直言）。

也就是说，这只会将您的问题的答案更改为“取决于” - 特别是，它取决于 IEnumerable 实际上在幕后是什么。如果它恰好已经是一个 List，那么 ToList 将实际上是免费的，当然 会比其他类型快得多。它仍然不是超级快。

当然，解决这个问题的最佳方法是尝试弄清楚如何在 IEnumerable 而不是 List 上进行处理。这可能是不可能的。

---

编辑：cmets 中的一些人正在争论 ToList() 在 List 上调用时是否实际上会比不调用时更快，以及 ToList() 是否会比列表构造函数更快。至此，猜测已经没有意义了，所以这里有一些代码：

using System;
using System.Linq;
using System.Collections.Generic;

public static class ToListTest
{
    public static int Main(string[] args)
    {
        List<int> intlist = new List<int>();
        for (int i = 0; i < 1000000; i++)
            intlist.Add(i);

        IEnumerable<int> intenum = intlist;

        for (int i = 0; i < 1000; i++)
        {
            List<int> foo = intenum.ToList();
        }

        return 0;
    }
}

使用实际上是 List 的 IEnumerable 运行此代码比我用 LinkedList 或 Stack 替换它快 6-10 倍（在我的 pokey 2.4 GHz P4 上，使用 Mono 1.2.6）。可以想象，这可能是由于 ToList() 与 LinkedList 或 Stack 枚举的特定实现之间的一些不幸的交互，但至少要点仍然存在：速度将取决于 IEnumerable 的底层类型。也就是说，即使使用 List 作为源，我仍然需要 6 秒才能进行 1000 次 ToList() 调用，所以它远非免费。

下一个问题是 ToList() 是否比 List 构造函数更智能。答案是否定的：List 构造函数与 ToList() 一样快。事后看来，Jon Skeet 的推理是有道理的——我只是忘记了 ToList() 是一种扩展方法。我仍然（非常）在语法上更喜欢 ToList()，但没有使用它的性能理由。

所以简短的版本是最好的答案仍然是“如果可以避免的话，不要转换为列表”。除此之外，实际性能将在很大程度上取决于 IEnumerable 的实际情况，但充其量它会很缓慢，而不是冰冷的。我已经修改了我原来的答案以反映这一点。

Answer 6

通过阅读各种 cmets 和问题，我得到以下要求

对于一个数据集合，您需要遍历该集合，过滤掉一些对象，然后对剩余的对象执行一些转换。如果是这样的话，你可以这样做：

var result = from item in collection
             where item.Id > 10 //or some more sensible condition
             select Operation(item);

如果您需要执行更多过滤和转换，您可以嵌套您的 LINQ 查询，例如

var result = from filteredItem in (from item in collection
                                  where item.Id > 10 //or some more sensible condition
                                  select Operation(item))
                 where filteredItem.SomePropertyAvailableAfterFirstTransformation == "new"
                 select SecondTransfomation(filteredItem);