EF5 Performance Considerations

re: EF5 Performance Considerations

Diego B Vega — Mon, 16 Apr 2012 22:39:24 GMT

@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.

re: EF5 Performance Considerations

Diego B Vega — Mon, 16 Apr 2012 22:36:15 GMT

@cynic: Several internal classes and methods work together in the execution of EF queries. I hope this high level description will help you find the right methods when profiling your application, but keep in mind that details might change in future versions:

- Execution of every regular LINQ query starts when we call ELinqQueryState.GetExecutionPlan. This method will perform the first part of the query translation - go from LINQ Expression tress to DbExpression trees, using ExporessionCoverter and other nested classes - every time.

- Once we have a DbExpression tree we compute a key string based on it that we use to do a lookup in the query cache, using QueryCacheManager.TryCacheLookup.

- If we find a match we will use the existing plan, which includes the final SQL generation. If we don't find a match, we compute the plan with ObjectQueryExecutionPlan.Prepare and we add it to the cache (if the query is cacheable).

- Interleaved with all this, we need to handle parameters: Most of the interesting logic for LINQ queries is in the Funcletizer class.

- This class has a visitor that identifies access to closure variables that can be parameters in the LINQ expression tree an covertes them to an internal parameter class during the LINQ translation phase.

- It also has the logic necessary to evaluate the parameter values from the variables captured in closures that we later pass to DbParameters in the target query.

- Once we have the plan (an instance of ObjectQueryExecutionPlan), we pass the parameters to its Execute method, which will execute the command to obtain a DbDataReader which we will then pass to an instance of Shaper<T>, where the actual object materialization begins.

From the first version of EF there has always been an improvement between the execution time of the first query for a given model and app domain and the execution time of the second one (even if it was a completely different query) because view generation for a given model and connection only needs to happen once per app domain. There has always also been an improvement between the first execution of a particular query instance and the second execution of *the same query instance* because we cache the query execution plan internally in the query instance. One of the things that EF 5.0 improves over what we had in EF 4.0 is that now if you create and execute the same query repeated times (think about the same query code constructing a new query instance on every round trip in a Web application) we can also take advantage of the cache. This case is different from the previous one in that different instance of the same query hit the same cache entry.

The second part of the improvement in EF 5.0 is that when it comes to evaluating the values of parameters of LINQ queries in order to pass them to the underlying DbCommand, we do it in a way that is much more efficient.

Hope this helps,

Diego

re: EF5 Performance Considerations

Diego B Vega — Sat, 14 Apr 2012 21:01:30 GMT

@Mark and Roger: Thanks guys for the great feedback. Definitely we see many applications that only require trivial mapping and a very short (if any) unit of work. Although we could create a new "lighter" version of EF optimized for those scenarios I believe we can improve the current EF so that you less often have to pay a performance tax for features you aren’t using. As David mentions, we know there is room for improvement in many areas.

For specific feature requests, like optional unit of work and batch updates, I would like to encourage you to go to our UserVoice site (http://ef.mswish.net), vote for them or add them if you cannot find them.

re: EF5 Performance Considerations

Roger - Fenêtre — Sat, 14 Apr 2012 10:40:03 GMT

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).

re: EF5 Performance Considerations

Mark — Fri, 13 Apr 2012 18:58:01 GMT

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.

re: EF5 Performance Considerations

cynic — Wed, 11 Apr 2012 07:33:31 GMT

Also, could you tell what to methods look for on the call stack (in profilers and other tools) that correspond to the query execution stages outlined in "2. Cold vs. Warm Query Execution", esp. how to distinguish between "Parameter Evaluation", "Query Translation" and "Materializer Generation"?

How exactly does the "but cached" EF5 improvement work for "Query Translation" stage work? I am seeing and have always been seeing massive improvement during the second execution of a query in EF4 already (executed on different ObjectContext but with the same MetadataWorkspace), yet "Query Lookup" in EF4 is supposedly "Medium" cost, same as initial "Query Translation".

When can we expect official announcement on whether .NET 4.5 and EF5 core with it will support Windows XP? All the improvements would amount to nothing to those of us who have to support XP if .NET 4.5 can't be installed on in.

re: EF5 Performance Considerations

David Obando [MSFT] — Tue, 10 Apr 2012 17:40:49 GMT

Hi Ricardo. Unfortunately, there's no magic bullet for every model. We are working on performance improvements that will benefit everyone in upcoming releases of EF. Your feedback is taken serously and helps us define our priorities.

The switch from independent associations to foreign keys will benefit larger projects over smaller ones. Complex models with many associations, a large number of entities (and properties) and with extensive use of inheritance will benefit the most from this switch. How large is the model of your sample code?

re: EF5 Performance Considerations

Ricardo GER — Tue, 10 Apr 2012 13:21:06 GMT

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.

re: EF5 Performance Considerations

Sean Stenlund — Tue, 10 Apr 2012 01:55:37 GMT

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!

re: EF5 Performance Considerations

cynic — Sat, 07 Apr 2012 12:16:30 GMT

@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.