I really like LINQ feature in .NET. For me it’s what people call syntactic sugar. It allows me to reduce amount of code I’m writing dramatically in many cases. Look at the following example - http://pastebin.com/d10c04029
This code estimates mean and variance of distribution given a sequence of samples. Two versions are provided. The first one uses .NET 2.0 features only and the second uses LINQ. As you can see, LINQ version is very short and awesome-looking even for this very simple example.
Are there any drawbacks? Yeah, unfortunately. And, of course, that drawbacks are performance related. Let’s compare time required for processing sequence (System.Array of double) containing 50 million samples (drawn from [0,1]-uniform distribution if that matter something for someone):
Normal: mean=0,5000 var=0,0833 time=00:00:03.6591708
LINQ: mean=0,5000 var=0,0833 time=00:00:04.5832141
Why is the LINQ version 1.5 times slower? Well, the obvious answer is that it should call a function (which is not inlined) for every member of the sequence, at least while calculating variance, and the first version should not. And, probably, computational cost of a function call is comparable to a few math operations (as it should be). So, use LINQ as a syntactic sugar only when the function you want to apply to the sequence elements is much more complex than a few additions and multiplications or when your collection is small and you just don’t care about processing time.
Read more about LINQ performance there - http://davepeck.org/linq-collection-performance/.
Strange observation: when passing List<double> instead of array, LINQ version takes about 6 seconds while performance of the normal version does not change.