views:

1841

answers:

6

I have used .Net 3.5 and VS 2008 for more than a month. Like most .Net developers, I have evolved from years experience in .Net 1.0 & 2.0 and VS 2005. Just recently, I discovered the simplicity and power of LINQ and Lamda Expressions, as in my recent questions such as Find an item in list by LINQ, Convert or map a class instance to a list of another one by using Lambda or LINQ, and Convert or map a list of class to another list of class by using Lambda or LINQ.

I admit that Lambda and LINQ are much simpler and easy to read and they seem very powerful. Behind the scenes, the .Net compiler must generate lots of code to achieve those functions. Therefore I am little bit hesitant to switch to the new syntax since I already know the "old" way to achieve the same results.

My question is the about the efficiency and performance of Lambda and LINQ. Maybe Lambda expressions are mostly in-line functions, in that case I guess Lambda should be okay. How about LINQ?

Let's limit the discussion to LINQ-to-Objects LINQ-to-SQL (LINQ-to-SQL). Any comments, comparison and experiences?

A: 

In some cases LINQ is just as fast if not faster than other methods, but in other cases it can be slower. We work on a project that we converted to linq and the data lookup is faster but the merging of data between two tables is much slower. There is a little overhead, but in most cases I don't see the speed difference having much effect on your program.

ecspot
+7  A: 

There's no one single answer that will suffice here.

LINQ has many uses, and many implementations, and thus many implications to the efficiency of your code.

As with every piece of technology at our fingertips, LINQ can and will be abused and misused alike, and the ability to distinguish between that, and proper usage, is only dependent on one thing: knowledge.

So the best advice I can give you is to go and read up on how LINQ is really implemented.

Things you should check into are:

And as always, when looking at efficiency questions, the only safe approach is just to measure. Create a piece of code using LINQ that does a single, know, thing, and create an alternative, then measure both, and try to improve. Guessing and assuming will only lead to bad results.

Lasse V. Karlsen
A: 

For LINQ queries, with the 'new syntax', the IL (code) generated, is fundamentally no different than calling the extension methods provided by Enumerable and Queryable directly.

Michael Morton
+1  A: 

Dont optimize prematurely. Use Linq and the new extension methods liberally if they improve readability and profile your application afterwards.

Most times the difference between Linq and using plain for loops is not relevant at all. The improved maintainability of your code should be worth a few ms. Linq can be slower because it works on enumerators which are implemented as state machines. So plain for(...) loops will be faster.

I would recommend following Lasse V. Karlsens advice and append http://www.davesquared.net/2009/07/enumerables-linq-and-speed.html to his link list.

sbreitzke
+1  A: 

Technically the fastest way is to control all the minutia yourself. Here are some performance tests. Notice that the foreach keyword and the ForEach LINQ construct are identically far far slower than just using for and writing procedural code.

However, the compiler can and will be improved and you can always profile your code and optimize any problematic areas. It is generally recommended to use the more expressive features that make code easier to read unless you really need the extra nanoseconds.

George Mauer
That example is really not a good test. Firstly, he's comparing a single reverse iteration + delete to double iteration + list creation + delete. Secondly, why delete when you can instead *select the values you want*? This method, using LINQ is even faster than reverse-for + delete. Thirdly, he's not taking JIT into account, running my tests twice show that the second time around, the LINQ method is (surprisingly enough) 100x faster. My findings: http://img188.imageshack.us/img188/4408/linq.pngWhere "Silly LINQ" is his method of double iteration + creation + delete.
JulianR
Follow up: that test was not so much a test of LINQ versus "traditional constructs", as much as it's a test of efficient code vs inefficient code. For example, the List<T>.RemoveAll(Predicate<T> match) method is multiple times faster than the reverse-iteration + delete method, and certainly a lot prettier than writing this efficient way yourself! So I second your opinion to not use a method based on assumptions about efficiency that prove to be wrong ("elegant constructs are slow") but based on correctness.
JulianR
Cool, interesting stuff.
George Mauer
Failing to take into account the cost of the jitting is an extremely common error amongst people who don't have much experience writing realistic benchmarks. The closer to "reality" the scenario is, the better the results will be; benchmarking only the first call to a method is highly unrealistic. In reality, most performance problems are a result of millions of calls, only one of which is the first!
Eric Lippert
A: 

I believe this site uses linq to sql.

Matt