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

• Anonymous
  June 25, 2007
  Rico continues his series on LINQ to SQL performance. In this post he takes a look at the breakdown of

• Anonymous
  June 26, 2007
  I guess LINQ to Entity will have even more overhead?

• Anonymous
  June 26, 2007
  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.

• Anonymous
  June 26, 2007
  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! :-)

• Anonymous
  June 26, 2007
  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.

• Anonymous
  June 29, 2007
  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