为什么C＃编译器会对这个嵌套的LINQ查询感到厌烦？

Question

尝试编译以下代码，你会发现编译器需要> 3 GB的RAM（我机器上的所有可用内存）和很长的编译时间（实际上我在10分钟后得到IO异常）。

using System;
using System.Linq;

public class Test
{
    public static void Main()
    {
        Enumerable.Range(0, 1).Sum(a =>
        Enumerable.Range(0, 1).Sum(b =>
        Enumerable.Range(0, 1).Sum(c =>
        Enumerable.Range(0, 1).Sum(d =>
        Enumerable.Range(0, 1).Sum(e =>
        Enumerable.Range(0, 1).Sum(f =>
        Enumerable.Range(0, 1).Count(g => true)))))));
    }
}

任何人都可以解释这种奇怪的行为吗？

CS Version:     Microsoft (R) Visual C# Compiler version 4.0.30319.17929
OS Name:        Microsoft Windows 7 Ultimate
OS Version:     6.1.7601 Service Pack 1 Build 7601

Answer 1

我相信它与类型推断和/或lambda生成有关（当类型推断必须与正常方向相反时），结合重载决策。 不幸的是，只提供类型参数对情况没有帮助（它可能仍然需要执行类型检查）。

在分析了lambdas之后，以下代码在逻辑上应该是您的等效代码，编译没有问题：

static void Main()
{
    var x = Enumerable.Range(0, 1).Sum(a);
}

private static int a(int a)
{
    return Enumerable.Range(0, 1).Sum(b);
}
private static int b(int b)
{
    return Enumerable.Range(0, 1).Sum(c);
}
private static int c(int c)
{
    return Enumerable.Range(0, 1).Sum(d);
}
private static int d(int d)
{
    return Enumerable.Range(0, 1).Sum(e);
}
private static int e(int e)
{
    return Enumerable.Range(0, 1).Sum(f);
}
private static int f(int f)
{
    return Enumerable.Range(0, 1).Count(g);
}
private static bool g(int g)
{
    return true;
}

---

我相信Eric Lippert之前发布的类型推断是C＃编译器中的一个地方，其中（某些问题）可能会迫使编译器尝试解决NP-Complete问题，而其唯一真正的策略（如此处）是强力的。 如果我能找到相关的参考文献，我会在这里添加它们。

---

我能找到的最好的参考就是这里埃里克的讨论事实上，它是重载解析的工作，使真正的成本-记住， Enumerable.Sum有10个重载接受一个lambda /方法。