LINQ to SQL: Under the Microscope


Rico continues his series on LINQ to SQL performance. In this post he takes a look at the breakdown of where the time is being spent.  It’s not looking good for the extra overhead of query translation. Rico ponders a solution.


 Of course, if you ignore the one-time cost of JIT’ing the assembly, the translation overhead is only about 30% over the total cost; 60% is still reading the data which includes executing the query. Since we know that the ‘hot’ cost of using LINQ to SQL overall is 7 times more expensive than SqlDataReader alone, there’s still a large portion in the ‘reading the data’ section that is above and beyond SqlDataReader. That, of course, is the cost of materializing objects out of the results. That cost appears to be much larger than the upfront query translation; which I’m sure Rico will conclude in his next post.  Just stating the obvious. 🙂

Comments (6)

  1. Roller says:

    Rico continues his series on LINQ to SQL performance. In this post he takes a look at the breakdown of

  2. Justin Shen says:

    I guess LINQ to Entity will have even more overhead?

  3. mattwar says:

    It’s not clear where we’ll end up with L2E and EF, because its still undergoing its optimization work. However, since the problem is fundementally the same, the sames sorts of solutions should work.

  4. Anders Borum says:

    Matt,

    I’m going to ask you to come in on saturday .. and sunday .. to finish that beta 2 release. We need it like, yesterday, erm – the day before that!

    🙂

  5. mattwar says:

    Development-wise, we are already done with Beta 2, only ship-stopper level bugs are still being dealt with.  We are already working on writing bugs for RTM.

  6. rogerj says:

    There’s actual data that compares parameterized and compiled query performance with some updates on compiled queries and DataContext objects at http://oakleafblog.blogspot.com/2007/06/rico-mariani-dlinq-performance-tips.html.

    –rj