What does query plan caching do? Do I need to keep my ObjectQuery around to take advantage of query plan caching?

For Entity SQL queries, query plan caching stores information that is computed as part of putting together the query itself. By caching this information, a subsequent execution of the same query (even if you change parameter values) will run much faster than the first one. This information is cached per app domain, so you will generally benefit from the query cache across multiple client requests to the same web app and the like.

For LINQ queries, you need to use "compiled queries" to achieve this same effect. See the question below about compiled queries for more information on how to do that.

You do not have to keep an ObjectQuery instance around to take advantage of the query plan cache. Future ObjectQuery instances that use the same query string will automatically take advantage of it. For more information, see Performance Considerations for Entity Framework Applications.

From http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2363212&SiteID=1.

Show me the numbers. How good is EF performance?

Take a look at some relevant posts on the ADO.NET team blog starting with this one: EF Performance Comparison. For more information, see Performance Considerations for Entity Framework Applications.

Does creating large object hierarchies impact performance?

Yes. Entity models are not like class models, and inheritance has a performance and complexity cost that it does not have in pure code-based systems. The number of relationships also has an impact on performance.

How do I improve performance by using compiled queries?

The following articles discuss how to work with compiled queries:

• Precompiling LINQ Queries
• Compiled Queries
• Potential performance eissues with compiled linq query re-compiles
• Using pre-compiled linq-to-entities queries in web apps and services
• Maximizing Performance with the Entity Framework in an ASP.NET Web Application

Entity Data Model designer is slow when using a large number of tables (500+). What is the guidance for working with large models?

Unfortunately, there aren't very good workarounds at the moment. The best suggestion is to break the model into multiple smaller models. Generally the suggested target is 200 tables or fewer for each model. This is an area the EF team hopes to improve in future releases.

The following articles discuss how to work with large models:

• Working with Large Models in Entity Framework part 1
• Working with Large Models in Entity Framework part 2

What are some Entity Framework performance-related articles?

See the following articles:

• Performance Considerations
• EF Performance Comparison
• Exploring the performance of the EF - Part 1 and Part 2
• EF Query Tuning
• Maximizing Performance with the Entity Framework in an ASP.NET Web Application

What data caching is built in to the Entity Framework?

The EF doesn't have data caching built in. The EF does identity resolution, which is sometimes thought of as a first-level data cache, but it's not really a cache in the strict sense of the term. The EF does cache metadata and (as described above query plan information).

There are a couple of samples that show how to do some kinds of data caching:

• EF Caching with Jarek Kowalski's Provider
• EF Provider Wrappers
• Simple Query Results Caching with EF4