Question

I’m using MVC Mini Profiler and I’m trying to measure the impact the LINQ to SQL portion of the query (generating the expression tree, the actual SQL command, etc) versus the time that was spent on the database side.

I see an “aggregate duration of all queries in this step (excludes children)”. Does this include the LINQ to SQL portion and the database call, or only the database portion? When clicking on the “sql” link to see the list of queries that were ran I see a query duration. Again, does this include the LINQ portion or just the database side?

Thanks.

Answer 1

The SQL timings are just the SQL – since that is coming from the wrapped ADO.NET connection, and knows very little about the caller. To get detailed timings for that (to measure the overheads), wrap the code you are interested in:

using(profiler.Step("Get orders")) {
    orders = db.{some query}.ToList();
}

Now you have a timing for the unit of code, and inside that timing, the SQL timings that correspond to it. So if the “Get orders” code took 100ms, and the SQL took 40ms, then you have 60ms of overheads.

Things to reduce overhead:

• try precompiling the query
• try switching to ExecuteQuery<T>, so there is no expression tree to parse

From experience, though, you’ll probably find that most of those overheads come from “materialization” (i.e. turning the rows from the database into objects), especially in a high throughput scenario. We found the only way to shed that overhead was to use dapper-dot-net as a replacement to ExecuteQuery<T> (it has an intentionally similar API). With that, we have virtually no overheads between the timings for “Get orders”, and the timings for the SQL in that block.