Question

I started using compiled queries to increase the performance of some commonly executed linq to entities queries. In one scenario I only boiled the query down to it’s most basic form and pre-compiled that, then I tack on additional where clauses based on user input.

I seem to be losing the performance benefit of compiled queries in this particular case. Can someone explain why?

Here’s an example of what I’m doing…

IEnumerable<Task> tasks = compiledQuery.Invoke(context, userId); 

if(status != null)
{
    tasks = tasks.Where(x=x.Status == status);
}
if(category != null)
{
   tasks = tasks.Where(x=x.Category == category);
}

return tasks;

Answer 1

I think it’s important to understand how Compiled Queries in EF work.

When you execute a query Entity Framework will map your expression tree with the help of your mapping file (EDMX or with code first your model definitions) to a SQL query. This can be a complex and performance intensive task.

Precompiling stores the results of these mapping phase so the next time you hit the query it has the SQL already available and it only has to set the current parameters.

The problem is that a precompiled query will lose it’s performance benefit as soon as you modifie the query. Let’s say you have the following:

IQueryable query = GetCompiledQuery(); // => db.Tasks.Where(t => t.Id == myId);
var notModifiedResult = query.ToList(); // Fast
int ModifiedResult = query.Count(); // Slow

With the first query you will have all the benefits of precompiling because EF has the SQL already generated for you and can execute this immediatly.
The second query will lose the precompiling because it has to regenerate it’s SQL.

If you would now execute a query on notModifiedResult this will be a Linq To Objects one because you have already executed your SQL to the database and fetched all the elements in memory.

You can however chain Compiled Queries (that is, use a compiled query in another compiled query).

But your code would require a series of compiled queries:
– The default
– One where status != null
– One where category != null
– One where both status and category != null