Share via

EF5 Performance Considerations

  • Article

Over the past few weeks the EF team has been putting together a whitepaper that talks about the performance considerations developers should take when using Entity Framework. Performance is one critical aspect of developing modern applications, and this document will help developers make informed design decisions and get the most out of their applications when using the Entity Framework 5 (and also EF 4).

There’s no such thing as a magic bullet when it comes to performance. Some of the topics covered by this whitepaper are:

  • View generation.
  • Caching.
  • Query Execution Options.
  • Inheritance Strategies.
  • Lazy Loading vs. Eager Loading.
  • And more.

The document can be found here: https://msdn.microsoft.com/en-us/data/hh949853. So go ahead: read it, and let us know your thoughts.

David Obando,
Entity Framework Team

Comments

  • Anonymous
    April 05, 2012
    view generation is painfull in development stage, when we deoploy it is not an issue because it cache the views. I think the better option is generate the view on demand, whenever it encouters the query let generate the view only for that table. when the development stage normally we will use only few views at a time.

  • Anonymous
    April 05, 2012
    It's cute that you show that you care, but view generation performance is still not acceptable in EF5. " It's unknown how long it would have taken to generate the model that used independent associations." - why do you even need to treat your own code like a research subject, you wrote it yourselves, you should know why it takes so long and fix it.

  • Anonymous
    April 06, 2012
    @cynic: thank you for your interest in the performance of Entity Framework. We do care about view generation and its performance. The main goal of this white paper is to help people understand how EF behaves today and how to make the most of it. I am part of the team responsible for improving the performance of EF and I really appreciate listening what are the biggest pain points in production code. If you have specific examples that you want to share with us, please let me know. There are many performance improvements introduced by EF5, but clearly there is room for more. This white paper is a living document and we'll update it with relevant information as we make clear progress on areas such as view generation. Thanks, David Obando.

  • Anonymous
    April 06, 2012
    @David Obando Nothing you're not already aware of. You speak of the Navision model for which view generation takes over a month. Clearly, there is room for improvement there (and switching to FK associations is not an option, I want the features of independent associations and 104 minutes would still be way too much). I have a model for which view generation takes "only" 16 minutes, 15:30 of which consists of generating an update view for a single table (TPH, about 20 subtypes, participates in over a dozen associations), and it seems to double every month or so, as the team works on that entity set, and they hate it already (the problem appeared when we switched to TPH, if that's any hint). You could also change the way views are distibuted, because with literal strings they take twice as much space as they could be (UTF-16) and you soon hit the literal string limit in CLR assemblies. Why not pregenerate the OfType query views as well? They're not as expensive to create in the grand scheme of things, but ~2 secs extra cold startup time is unacceptable in desktop applications. Why not make the view generation efficient enough so that pre-generation is not necessary at all? "View generation" is your internal implementation detail, I haven't heard of any other ORM forcing their implementation concerns on users to achieve their basic features.

  • Anonymous
    April 09, 2012
    Thank you for this whitepaper.  Very informative and helpful at the right time.  It seems you EF folks are reading my mind at each stage of development on my project!

  • Anonymous
    April 09, 2012
    I can not understand the point "2.4.1 Using Foreign Key Associations to reduce view generation cost". Regardless of the sample code I run in a test, a model with "Foreign Key Associations" is always slower. I would appreciate an example or e-mail from you.

  • Anonymous
    April 10, 2012
    The comment has been removed

  • Anonymous
    April 10, 2012
    The comment has been removed

  • Anonymous
    April 13, 2012
    Please consider making a EF-Lite, keep LINQ but have it work against plain objects, not run-time tweaks of any kind, no state tracking, nothing that woul get in the way of performance. LINQ would be only for compile-time checking and nothing else. The mantra should be performance above all! Keep it within x1-x1.5 of raw ADO.NET and you'll see tons of big sites using it.

  • Anonymous
    April 13, 2012
    First of all thanks for investing serious time in such an important part of the framework. Performance is key in the success of every application. As we build a lot of disconnected web applications with EF, using short unit of works with the manager pattern and multiple users, first level caching and other objectcontext features are not very useful. Mark's idea of a light context (with f.e. poco, fast (de)serialization and linq) in combination with second level caching would give super performance! As MS is going more and more to the disconnected world in W8, please consider this! The second level example yiou provided in the paper is not production ready. I would be great if this at least would be supported! Furthermore please consider to add bulk update and delete as this increases performance a lot and is a often used functionality is business apps (working example: github.com/.../readme.md).

  • Anonymous
    April 14, 2012
    The comment has been removed

  • Anonymous
    April 16, 2012
    The comment has been removed

  • Anonymous
    April 16, 2012
    @cynic: I don't have any information on whether .NET 4.5 will work in Windows XP, but I can tell you that we are planning to make EF more independent of the version of .NET in the future, so that hopefully we will get to a point in which we will be able to release a version of EF that is compatible with .NET 4.0 but has these perf improvements. It is too early to know when that is going to be the case though.

  • Anonymous
    October 29, 2013
    hi,can you give us some suggestions about raise performance with EF,we compared it with sql,specially long running test,It's often time out with linq in ef.but sql works.

  • Anonymous
    October 30, 2013
    @soderberg - The best place to start would be the document linked to from this post - http://msdn.com/data/hh949853. If you have specific questions after that, post them on StackOverflow.com using the entity-framework tag (be sure to include code showing the scenario that is performing poorly).