| Today I've got a comment on my post where I compared performance of LINQ vs. DAAB vs. ADO.NET, saying that I should repeat my test with .NET Framework 3.5 beta 2. Indeed there are a lot of posts about performance improvements introduced in it, so I've rushed and repeated my test, compiling it in Microsoft Visual Studio 2008 Beta 2, targeting .NET 3.5 beta 2.|
Not sure that proverb "no news - good news" is correct in this case, but - well - no news. I mean that performance results are absolutely the same - LINQ is about 30% slower than raw ADO.NET (4.28 ms per call for ADO.NET vs. 5.51 ms per call for LINQ). Also, using LINQ rather than ADO.NET makes application much more CPU intensive (something like ~20% of CPU intensity with LINQ vs. ~2% of CPU intensity with ADO.NET - difference of order of magnitude!). You may see screenshots below.
CPU Intensity.(First third - ADO, second - DAAB, third - LINQ.)
So it seems to me that there are no significant performance improvements, unless there is something fundamentally wrong with my tests (check code here).
Yet - I want to develop here something I've mentioned in my previous post. This additional performance cost doesn't mean "don't use LINQ". You'll probably never will get to performance incur of 30% in the real project. In the real life scenario you'll never abuse your DB by shooting thousands of SP calls in a batch, without doing something with results. There is always some business logic around, some DAL, some timings, etc - so the performance costs are never so high and they will be spread around evenly, rather than composed into a performance-loss peak. Also - mind that LINQ greatly improves coding productivity, decreases amount of code and project complexity. This means that developers would spend less timing coding and the costly thing for the project is the developer time. In the very worst case - profile your application to find the bottlenecks of 20:80 rule and use ADO.NET in critical sections of your code. And buy quicker CPU - they are cheap today :) ...
Few links to related articles: