如何判断 IEnumerable<T> 是否需要延迟执行？

Question

我一直认为，如果我在 LINQ to 对象的上下文中使用 Select(x=> ...)，那么新集合将立即创建并保持静态。我不太确定我为什么假设这个，这是一个非常糟糕的假设，但我做到了。我经常在其他地方使用.ToList()，但在这种情况下通常不会。

此代码表明，即使是简单的“选择”也会延迟执行：

var random = new Random();
var animals = new[] { "cat", "dog", "mouse" };
var randomNumberOfAnimals = animals.Select(x => Math.Floor(random.NextDouble() * 100) + " " + x + "s");

foreach (var i in randomNumberOfAnimals)
{
    testContextInstance.WriteLine("There are " + i);
}

foreach (var i in randomNumberOfAnimals)
{
    testContextInstance.WriteLine("And now, there are " + i);
}

这会输出以下内容（每次迭代集合时都会调用随机函数）：

There are 75 cats
There are 28 dogs
There are 62 mouses
And now, there are 78 cats
And now, there are 69 dogs
And now, there are 43 mouses

我在很多地方都有IEnumerable<T> 作为班级成员。 LINQ 查询的结果通常分配给这样的IEnumerable<T>。通常对我来说，这不会导致问题，但我最近在我的代码中发现了一些地方，它不仅会造成性能问题。

在尝试检查我犯了这个错误的地方时，我想我可以检查一个特定的IEnumerable<T> 是否属于IQueryable 类型。我想这会告诉我收藏是否“推迟”。事实证明，上面 Select 运算符创建的枚举器的类型是 System.Linq.Enumerable+WhereSelectArrayIterator``[System.String,System.String] 而不是 IQueryable。

我使用Reflector 来查看这个接口继承自什么，结果证明它根本没有从任何表明它是“LINQ”的东西继承——因此无法根据集合类型进行测试。

我很高兴现在将.ToArray() 放在任何地方，但我希望有一个机制来确保这个问题将来不会发生。 Visual Studio 似乎知道如何做到这一点，因为它给出了一条关于“扩展结果视图将评估集合”的消息。

我想出的最好的是：

bool deferred = !object.ReferenceEquals(randomNumberOfAnimals.First(),
                                        randomNumberOfAnimals.First());

编辑：这仅适用于使用“选择”创建新对象且不是通用解决方案的情况。无论如何我都不推荐它！这是解决方案的一个小舌头。

Answer 1

关于扩展结果视图将评估集合的消息是为所有IEnumerable 对象呈现的标准消息。我不确定是否有任何万无一失的方法来检查IEnumerable 是否被推迟，主要是因为即使yield 也被推迟了。绝对确保不会延迟的唯一方法是接受ICollection 或IList<T>。

Answer 2

手动实现一个懒惰的IEnumerator<T> 是绝对有可能的，所以没有“完全通用”的方法。我要记住的是：如果我在枚举与之相关的内容时更改列表中的内容，请始终在 foreach 之前调用 ToArray()。

Answer 3

一般来说，我会说你应该尽量避免担心它是否被推迟。

IEnumerable<T> 的流式执行性质具有优势。这是真的 - 有时它是不利的，但我建议总是专门处理那些（罕见的）时间 - 要么转到 ToList() 或 ToArray() 将其转换为适当的列表或数组。

剩下的时间，最好让它被推迟。需要经常检查这似乎是一个更大的设计问题......

Answer 4

延迟执行 LINQ 让很多人陷入困境，你并不孤单。

我为避免这个问题所采取的方法如下：

方法的参数 - 使用IEnumerable<T>，除非需要更具体的接口。

局部变量 - 通常在我创建 LINQ 的时候，所以我会知道是否可以进行惰性求值。

类成员 - 永远不要使用 IEnumerable<T>，始终使用 List<T>。并始终将它们设为私有。

属性 - 使用IEnumerable<T>，并在setter 中转换为存储。

public IEnumerable<Person> People 
{
    get { return people; }
    set { people = value.ToList(); }
}
private List<People> people;

虽然存在这种方法行不通的理论案例，但我还没有遇到过这种情况，而且自 Beta 后期以来我一直在热情地使用 LINQ 扩展方法。

顺便说一句：我很好奇你为什么使用 ToArray(); 而不是 ToList(); - 对我来说，列表有更好的 API，而且（几乎）没有性能成本。

更新：一些评论者正确地指出数组具有理论上的性能优势，因此我将上面的陈述修改为“......（几乎）没有性能成本。”

更新 2：我编写了一些代码来对数组和列表之间的性能差异进行一些微基准测试。在我的笔记本电脑上，在我的特定基准测试中，每次访问的差异约为 5ns（即 nano 秒）。我想在某些情况下，每个循环节省 5ns 是值得的……但我从来没有遇到过。在运行时间长到足以准确测量之前，我必须将测试提高到 100 百万次迭代。

Answer 5

这是对延迟执行的一种有趣反应 - 大多数人认为它是积极的，因为它允许您转换数据流而无需缓冲所有内容。

您建议的测试不起作用，因为迭代器方法没有理由不能在两次连续尝试中产生与其第一个对象相同的引用对象实例。

IEnumerable<string> Names()
{
    yield return "Fred";
}

这将每次返回相同的静态字符串对象，作为序列中的唯一项。

由于您无法可靠地检测从迭代器方法返回的编译器生成的类，因此您必须做相反的事情：检查一些知名容器：

public static IEnumerable<T> ToNonDeferred(this IEnumerable<T> source)
{
    if (source is List<T> || source is T[]) // and any others you encounter
        return source;

    return source.ToArray();
}

通过返回IEnumerable<T>，我们将集合保持为只读，这很重要，因为我们可能会取回副本或原件。

Answer 6

我的五美分。很多时候你必须处理一个你不知道里面有什么的枚举。

您的选择是：

• 在使用前将其列在列表中，但您可能会遇到无穷无尽的麻烦
• 按原样使用，你很可能会面临各种延期执行的搞笑事情，你又遇到麻烦了

这是一个例子：

[TestClass]
public class BadExample
{
    public class Item
    {
        public String Value { get; set; }
    }
    public IEnumerable<Item> SomebodysElseMethodWeHaveNoControlOver()
    {
        var values = "at the end everything must be in upper".Split(' ');
        return values.Select(x => new Item { Value = x });
    }
    [TestMethod]
    public void Test()
    {
        var items = this.SomebodysElseMethodWeHaveNoControlOver();
        foreach (var item in items)
        {
            item.Value = item.Value.ToUpper();
        }
        var mustBeInUpper = String.Join(" ", items.Select(x => x.Value).ToArray());
        Trace.WriteLine(mustBeInUpper); // output is in lower: at the end everything must be in upper
        Assert.AreEqual("AT THE END EVERYTHING MUST BE IN UPPER", mustBeInUpper); // <== fails here
    }
}

所以没有办法摆脱它，只有一个方法：在运行的基础上精确地迭代一次。

对于立即和延迟执行场景使用相同的 IEnumerable 接口显然是一个糟糕的设计选择。这两者之间必须有明确的区别，以便从名称或通过检查属性可以清楚地看出枚举是否被延迟。

提示：在您的代码中考虑使用IReadOnlyCollection<T> 而不是普通的IEnumerable<T>，因为除此之外您还获得了Count 属性。这样你就确定它不是无穷无尽的，你可以把它变成一个列表没有问题。