编译器是否连接 LINQ where 查询？

Question

考虑以下两个相似的代码示例。

一个where 子句。

bool validFactory
  = fields
    .Where(
      fields => field.FieldType == typeof( DependencyPropertyFactory<T> ) &&
                field.IsStatic )
    .Any();

两个where 子句。

bool validFactory
  = fields
    .Where( field => field.FieldType == typeof( DependencyPropertyFactory<T> ) )
    .Where( field => field.IsStatic )
    .Any();

我更喜欢第二个，因为我发现它更具可读性，并且导致的格式问题更少，尤其是在使用自动格式时。将 cmets 放在单独的条件旁边（甚至上面）以阐明意图时也更清楚。

我的直觉说第二个代码示例效率会降低。我当然可以自己编写一个简单的测试（如果没有人知道答案，我也会这样做）。现在我认为这是完美的食物。 ;p

1. 一个比另一个更有效吗？
2. 编译器是否足够聪明，可以对此进行优化？

Answer 1

不允许编译器对此进行优化，因为它不知道 Where() 的作用。例如，您可能使用记录其结果的版本重载了 Where()。 （抖动可以做优化，但实际上不太可能。）

效率差异不太可能显着。您可以分析您的应用程序以查看它是否重要。

更新：显然抖动确实在这里执行优化。请参阅 Eric Lippert 的回答。

Answer 2

我不希望这里有显着差异。但是，如果您强制枚举集合，那么我预计会有更多不同

bool validFactory   = fields
    .Where( field => field.FieldType == typeof( DependencyPropertyFactory<T> ) )
    .ToList()
    .Where( field => field.IsStatic )     
    .ToList()
    .Any(); 

在您的两个原始代码示例中，我看到相同的执行 - 第一项检查 FieldType，然后检查 IsStatic，如果存在则返回 true。否则检查第二项，依此类推。整个集合不需要解析。

在上面的示例中，整个集合将被解析为 FieldType，独立于 IsStatic 检查。这可能效率较低。请注意，这在您的任何一个 sn-ps 中都不是必需的。

Answer 3

编译器不会尝试优化连续的“where”调用。 运行时库会这样做。如果您有一大堆“where”和“select”调用并排在一起，运行时将尝试将它们重新组织成更有效的形式。

在一些不寻常的情况下，“优化”当然会使事情变得更糟。我似乎记得 Jon Skeet 最近写了一篇关于这个的文章，虽然我不确定它在哪里。