Mining the performance of Ado.net Entity Framework

Ado. NET team recently discussed the various performance characteristics of the Ado.net Entity Framework. The Ado.net Entity Framework has entered its third beta version in December, and since then the development team has been providing information to developers about using the framework. Now, the developer is provided with information about the framework's performance.

This paper introduces the performance of Ado.net Entity Framework, demonstrates how to improve the so pertinent of simple query speed, and illustrates the performance characteristics of the framework.

It is important to point out that when an abstraction layer or a module like an EDM (Entity Data Model) is used to transform the relational style of a database, there is a certain loss of performance.

Query and Results

This article uses the Northwind database as a model and creates a simple query:

(NorthwindEntities ne =　NorthwindEntities())
{
(Order o　ne.Orders)
{
i = o.OrderID;
}
}

At the time of the test, each of our queries had 10 traversal of the entire 848 rows of data. The result was interesting, and the 1th time it took 4241 milliseconds to run, and the next run averaged about 13 milliseconds. The most time-consuming part of the content is the creation of ObjectContext, and there are some time-consuming actions that occur when you perform any of the operations that access the database.

The percentage value per operation can give us some insight:

Load meta data (11%)

Initializing meta data (14%)

Open Connection (8%)

Build View (56%)

Mount Assembly (2%)

Tracking (1%)

Instantiation (7%)

Other (1%)

The most time-consuming percent value is the view generation, which reaches an astonishing 56%. Since view generation is the culprit for performance loss, it is best for developers to use the command-line tools EDM Builder (EdmGen.exe), which requires the runtime to add View Generation command parameters (/ mode:viewgeneration), its output is a code file (C # or vb.net) that can be included in the project. The pre-build of the view can reduce the startup time to 2933 milliseconds, for circular traversal operations, the entire time can be reduced by 28%. Building views and publishing them along with the application is a recipe for performance improvement, but the downside is that the view is no longer dynamic, and once the model changes, it needs to be rebuilt to keep it synchronized.

Query performance

It is important to note that the main design element for performance is query caching. Once a query is executed, part of it is maintained in the global cache. Because of the existence of the query and the metadata cache, the second run is always faster than the first run. For example, the following Entity SQL query:

(PerformanceArticleContext ne =　PerformanceArticleContext())
{
ObjectQuery orders = ne.CreateQuery();
(Orders o　orders)
{
i = o.OrderID;
}
}