| 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.  Timing results  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 :) ... P.S. Few links to related articles:
|
Wednesday, September 19, 2007
.NET 3.5 Beta 2 - no LINQ performance improvements?
Subscribe to:
Post Comments (Atom)
3 comments:
Well, that's beacuse the Frameworks from 2.0 (2.0, 3.0, 3.5) have been all been riding on many of the same assemblies of CLR 2.0. There was no new System.Data released as part of Framework 3.5; it's still the CLR 2.0 version, which explains why there were no improvements.
I guess the other issue is that performance loss is performance loss, no matter how you spread it around, it adds back up to the original raw performance degradation. The only mitigating factors would be if there were asynchronous/threaded tasks that the data access had to wait on (in some correltation of the threaded results), or if human itneraction could be factored in to obsolesce the slower LInQ performance.
According to one of the speaker from Microsoft Seminar that I attend to... LINQ is still not suitable and comparable in terms of performance in quering very large object in a database.
Post a Comment