何时不使用产量（返回）[重复]

Question

这个问题在这里已经有了答案：
Is there ever a reason to not use 'yield return' when returning an IEnumerable?

关于yield return 的好处，这里有几个有用的问题。例如，

• Can someone demystify the yield keyword

• Interesting use of the c# yield
  keyword

• What is the yield keyword

我正在寻找关于何时不使用yield return 的想法。例如，如果我预计需要返回集合中的所有项目，它 似乎 像 yield 一样有用，对吧？

在哪些情况下yield 的使用会受到限制、不必要、给我带来麻烦或应该避免？

Answer 1

在哪些情况下使用 yield 会受到限制、不必要、给我带来麻烦或应该避免？

在处理递归定义的结构时，最好仔细考虑您对“收益回报”的使用。比如我经常看到这样的：

public static IEnumerable<T> PreorderTraversal<T>(Tree<T> root)
{
    if (root == null) yield break;
    yield return root.Value;
    foreach(T item in PreorderTraversal(root.Left))
        yield return item;
    foreach(T item in PreorderTraversal(root.Right))
        yield return item;
}

看起来非常合理的代码，但它存在性能问题。假设树的深度为 h。然后最多会构建 O(h) 嵌套迭代器。然后在外部迭代器上调用“MoveNext”将对 MoveNext 进行 O(h) 嵌套调用。由于它对具有 n 项的树执行此操作 O(n) 次，因此算法为 O(hn)。并且由于二叉树的高度是 lg n

但是迭代一棵树在时间上可能是 O(n)，在堆栈空间中可能是 O(1)。你可以这样写：

public static IEnumerable<T> PreorderTraversal<T>(Tree<T> root)
{
    var stack = new Stack<Tree<T>>();
    stack.Push(root);
    while (stack.Count != 0)
    {
        var current = stack.Pop();
        if (current == null) continue;
        yield return current.Value;
        stack.Push(current.Left);
        stack.Push(current.Right);
    }
}

它仍然使用收益回报，但更聪明。现在我们的时间是 O(n)，堆空间是 O(h)，堆栈空间是 O(1)。

进一步阅读：请参阅 Wes Dyer 关于该主题的文章：

http://blogs.msdn.com/b/wesdyer/archive/2007/03/23/all-about-iterators.aspx

Answer 2

使用yield的情况有哪些 将是限制性的，不必要的，得到我 陷入困境，否则应该 避免？

我能想到几个案例，IE：

• 在返回现有迭代器时避免使用 yield return。示例：

  // Don't do this, it creates overhead for no reason
  // (a new state machine needs to be generated)
  public IEnumerable<string> GetKeys() 
  {
      foreach(string key in _someDictionary.Keys)
          yield return key;
  }
  // DO this
  public IEnumerable<string> GetKeys() 
  {
      return _someDictionary.Keys;
  }
  

• 当您不想延迟方法的执行代码时，请避免使用 yield return。示例：

  // Don't do this, the exception won't get thrown until the iterator is
  // iterated, which can be very far away from this method invocation
  public IEnumerable<string> Foo(Bar baz) 
  {
      if (baz == null)
          throw new ArgumentNullException();
       yield ...
  }
  // DO this
  public IEnumerable<string> Foo(Bar baz) 
  {
      if (baz == null)
          throw new ArgumentNullException();
       return new BazIterator(baz);
  }
  

Answer 3

要了解的关键是yield 的用途，然后您可以决定哪些情况不会从中受益。

换句话说，当您不需要延迟评估序列时，您可以跳过使用yield。那会是什么时候？当您不介意立即将整个收藏放在内存中时。否则，如果您有一个会对内存产生负面影响的巨大序列，您可能希望使用yield 逐步处理它（即懒惰地）。在比较这两种方法时，分析器可能会派上用场。

请注意大多数 LINQ 语句如何返回 IEnumerable<T>。这使我们能够不断地将不同的 LINQ 操作串在一起，而不会对每一步的性能产生负面影响（也称为延迟执行）。另一种情况是在每个 LINQ 语句之间放置一个 ToList() 调用。这将导致在执行下一个（链接的）LINQ 语句之前立即执行每个前面的 LINQ 语句，从而放弃惰性求值的任何好处并在需要时使用IEnumerable<T>。

Answer 4

这里有很多很好的答案。我要添加一个：不要对您已经知道值的小型或空集合使用 yield return：

IEnumerable<UserRight> GetSuperUserRights() {
    if(SuperUsersAllowed) {
        yield return UserRight.Add;
        yield return UserRight.Edit;
        yield return UserRight.Remove;
    }
}

在这些情况下，创建 Enumerator 对象比仅生成数据结构更昂贵、更冗长。

IEnumerable<UserRight> GetSuperUserRights() {
    return SuperUsersAllowed
           ? new[] {UserRight.Add, UserRight.Edit, UserRight.Remove}
           : Enumerable.Empty<UserRight>();
}

更新

这是my benchmark的结果：

这些结果显示了执行 1,000,000 次操作所需的时间（以毫秒为单位）。数字越小越好。

在重新审视这一点时，性能差异并不足以担心，因此您应该选择最容易阅读和维护的东西。

更新 2

我很确定上述结果是在禁用编译器优化的情况下实现的。使用现代编译器在发布模式下运行，看起来两者的性能几乎没有区别。选择对你来说最易读的东西。

Answer 5

Eric Lippert 提出了一个很好的观点（可惜 C# 没有 stream flattening like Cw）。我要补充一点，有时枚举过程由于其他原因很昂贵，因此如果您打算多次迭代 IEnumerable，则应该使用列表。

例如，LINQ-to-objects 是建立在“收益回报”之上的。如果您编写了一个慢速 LINQ 查询（例如，将一个大列表过滤成一个小列表，或者进行排序和分组），最好在查询结果上调用 ToList() 以避免枚举多个次（实际上多次执行查询）。

如果您在编写方法时在“yield return”和List<T> 之间进行选择，请考虑：每个元素的计算成本是否很高，调用者是否需要多次枚举结果？如果您知道答案是肯定的，那么您不应该使用yield return（除非，例如，生成的列表非常大并且您负担不起它将使用的内存。请记住，yield 的另一个好处是结果列表不必一次完全在内存中）。

不使用“yield return”的另一个原因是交错操作是否危险。例如，如果您的方法看起来像这样，

IEnumerable<T> GetMyStuff() {
    foreach (var x in MyCollection)
        if (...)
            yield return (...);
}

如果 MyCollection 有可能因为调用者所做的某事而改变，这是很危险的：

foreach(T x in GetMyStuff()) {
    if (...)
        MyCollection.Add(...);
        // Oops, now GetMyStuff() will throw an exception
        // because MyCollection was modified.
}

yield return 可能会在调用者更改让让函数假定不会更改的内容时引起麻烦。

Answer 6

当您需要随机访问时，产量将受到限制/不必要。如果您需要访问元素 0 和元素 99，那么您几乎消除了惰性求值的用处。

Answer 7

如果该方法具有您期望调用该方法的副作用，我将避免使用yield return。这是由于 Pop Catalin mentions 的延迟执行造成的。

一个副作用可能是修改系统，这可能发生在像IEnumerable<Foo> SetAllFoosToCompleteAndGetAllFoos() 这样的方法中，它破坏了single responsibility principle。这很明显（现在......），但不太明显的副作用可能是设置缓存结果或类似优化。

我的经验法则（再次，现在......）是：

• 只有在返回的对象需要一些处理时才使用yield
• 如果我需要使用yield，该方法没有副作用
• 如果必须产生副作用（并将其限制为缓存等），请不要使用 yield，并确保扩展迭代的好处大于成本

Answer 8

如果您正在序列化枚举的结果并通过网络发送它们，可能会引起您的注意。因为执行被推迟到需要结果时，您将序列化一个空枚举并将其发送回，而不是您想要的结果。

Answer 9

我必须维护一个绝对痴迷于收益回报和 IEnumerable 的人的一堆代码。问题是我们使用的许多第三方 API 以及我们自己的许多代码都依赖于列表或数组。所以我最终不得不这样做：

IEnumerable<foo> myFoos = getSomeFoos();
List<foo> fooList = new List<foo>(myFoos);
thirdPartyApi.DoStuffWithArray(fooList.ToArray());

不一定很糟糕，但处理起来有点烦人，并且在某些情况下会导致在内存中创建重复的列表以避免重构所有内容。

Answer 10

如果您不希望代码块返回迭代器以顺序访问底层集合，则不需要yield return。您只需 return 收藏即可。

Answer 11

如果您要定义一个 Linq-y 扩展方法，并在其中包装实际的 Linq 成员，那么这些成员通常会返回一个迭代器。没有必要自己通过该迭代器产生。

除此之外，使用 yield 定义一个基于 JIT 评估的“流式”枚举真的不会有太大的麻烦。