LINQ Performance versus ADO.NET
Sunday, August 19th, 2007
Last week I presented Deeper in LINQ for the Wisconsin .NET User Group and concluded with a speed test. The speed test compared ADO.NET to LINQ. The ADO.NET method called a stored procedure while the LINQ method generated the query inline. The results showed that LINQ is not as fast. The overhead is due to the LINQ for SQL provider that has to parse the query within the CLR and then generate the SQL that it sends over to SQL Server. The generated SQL is identical to what is in the stored procedure used by the ADO.NET method. The difference in timing is purely from preparing the query. And since LINQ to SQL uses ADO.NET once it generates the SQL it cannot possibly run faster than a direct ADO.NET implementation. The speed test was simply to show the difference.
[ Download the sample project: DeeperInLINQ.zip ]
In the attached screenshot you can see three tests. I wanted to make a LINQ sample that runs much faster so I added the second test to show how long it would take to have LINQ call the stored procedure just like the ADO.NET method and avoid the overhead of preparing the query. It seems that even though the original LINQ method is running the same query over and over it still has to carry out the preparation for the query each time. This is clearly an area that could be tuned prior to the .NET 3.5 release. In the meantime, the call to the stored procedure allows the new LINQ method to perform nearly as well as the ADO.NET version. If this particular method was performing poorly in a real application, breaking out the work to a stored procedure would be a good tuning option. But most of the time you will want to continue with inline LINQ queries so you get the productivity benefits that it provides through Intellisense and other features.



