Why does the C# compiler go mad on this nested LINQ query? -

try compile following code , you'll find compiler takes >3 gb of ram (all free memory on machine) , long time compile (actually io exception after 10 minutes).

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)))))));     } } 

can explain curious behavior?

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

i believe it's related type inference and/or lambda generation (when type inference has go in opposite direction normal), combined overload resolution. unfortunately, supplying type parameters doesn't situation (where presumably still has perform type checking).

the following code, should logically equivalent code yours, after lambdas have been analyzed, compiles without issue:

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; } 

---

i believe eric lippert has posted before type inference 1 of places in c# compiler (certain problems) may force compiler try solve np-complete problem , real strategy (as here) brute force. if can find relevant references, i'll add them here.

---

the best reference can find here eric's discussing fact it's overload resolution work causes real cost - remember, enumerable.sum has 10 overloads accept lambda/method.