Getting performance benefit from DbContext[EF 5] in Entity Framework

I did talk about the distributed architecture here with Entity framework code-first.

Now I would like to reminds you about the performance benefit features come with DBContext and it will also help you to extend your repositories and queries. Here is the followings:

No Tracking and Auto-Compiled Queries: 

In my early version of repository pattern, I have used ObjectQuery to get the features  of MargeOption and EnablePlanCaching properties.  

Setting MergeOption to NoTracking has helped us to take advantage of the EF ability to return data that doesn’t need to be tracked by the context. Say I don’t have any plan to make changes to that data. Therefore, I like to avoid the performance hit taken when EF creates ObjectStateEntry instances for each object it’s tracking, as well as forcing the context to be aware of any changes made to those objects.  EF Team has realized needs here and they have provided you an extension method of IQueryable - AsNoTracking()[Where(expression).AsNoTracking()].

Settting EnablePlanCaching to true has been used for enabling the caching plan first time it has been executed and next there was no more complexity for creating TSQL from LinqToEntities. You could also achieve this by using CompiledQuery Class to re-use precompiled query. Unfortunately there is no way to use CompiledQuery in DbContext API. CompiledQuery works only with ObjectContext. If we are using Code First, we are using the DbContext API. EF team has provided auto-compiled queries, which work very differently than CompiledQuery. Instead of your writing code to compile each query and then invoking each as needed, Entity Framework caches the generated SQL for you as a background process, then searches the cache for already compiled queries when you execute any query. It solves many issues of pre-compiled queries and gives us flexibility to cached 800 queries Item. And most wonderful news is you don’t need to write any code or project conversion to 4.5 to achieve this. All you need is .NET 4.5 runtime in your machine.

Find Method:

As you know, Find method is providing you to find object with its key and there is also performance benefit lies here. The Find method will first look in memory for a matching object that is being tracked by the context. If that is found in memory, then Entity Framework won’t bother querying the database. So, no more visit to database and mapping complexity if it is already there my memory.

Turn off Detect Changes and Validation:

I have found DBContext more organized and friendly in place of ObjectContext. Now user has the full flexibility to turn off and turn on the calling of change detection and validation. You can find this under the Property Configuration. Change tracking and the DetectChanges method are a part of the stack where there is a penalty of performance. For this reason it can be useful to have an idea of what is actually going on such you can make an informed decision on what to do if the default behaviour is not right for your application. If your context is not tracking a large number of entities you pretty much never need to switch off automatic DetectChanges otherwise I will suggest you turned it off and call DetectChanges where it seems necessary.

First Level Caching

There are also some features like Local property which provide you the first level in-memory caching objects available in state entries without the deleted marked objects and you can get the benefit if you want during the life time of a Context instance.

OK, that is it. Thanks for reading.

References

• A Few of My Favorite Things… in the Entity Framework 4.2 DbContext
• Performance Considerations for Entity Framework 5  
• Improve Performance with Entity Framework 5