- \n
- Compiled models dramatically reduce startup time for your application.<\/li>\n
- The models are generated (similar to how migrations are) so they should be refreshed whenever your model changes.<\/li>\n
- Some features are not currently supported by compiled models, so be aware of the limitations when you try them out.<\/li>\n<\/ul>\n
Background<\/h2>\n
How does 10x performance sound to you?<\/em> Our team created a sample project with a
DbContext<\/code> that contains 449 entity types, 6,390 properties and 720 relationships<\/strong>. I wrote a console app that loops several times, creates a new instance of aDbContext<\/code> and loads a set of entities with no filters or ordering. The start-up time for the first run consistently takes around two seconds<\/strong> on my laptop, with subsequent cached instances weighing in at about 1.5 seconds. Here’s the output from a run:<\/p>\n$ dotnet run -c Release\r\nModel has:\r\n 449 entity types\r\n 6390 properties\r\n 720 relationships\r\nInstantiating context...\r\nIt took 00:00:02.1603163.\r\nInstantiating context...\r\nIt took 00:00:01.6268628.\r\nInstantiating context...\r\nIt took 00:00:01.7144346.\r\nInstantiating context...\r\nIt took 00:00:01.6090380.\r\nInstantiating context...\r\nIt took 00:00:01.7049987.<\/code><\/pre>\nAfter testing the baseline application, I used the new EF Core tools Command Line Interface (CLI)<\/a> feature to optimize the
DbContext<\/code>:<\/p>\ndotnet ef dbcontext optimize -output-dir MyCompiledModels --namespace MyCompiledModels<\/code><\/pre>\nThe tool gave me instructions to add a single line of code to my
DbContext<\/code> configuration:<\/p>\noptions.UseModel(MyCompiledModels.BlogsContextModel.Instance);<\/code><\/pre>\nI made the update and re-ran the code to receive a 10x performance gain<\/strong> with the initial model taking 257ms<\/strong> to complete. The cached model reduced additional calls to just 10ms<\/strong>.<\/p>\n
$ dotnet run -c Release\r\nModel has:\r\n 449 entity types\r\n 6390 properties\r\n 720 relationships\r\nInstantiating context...\r\nIt took 00:00:00.2573627.\r\nInstantiating context...\r\nIt took 00:00:00.0132345.\r\nInstantiating context...\r\nIt took 00:00:00.0119556.\r\nInstantiating context...\r\nIt took 00:00:00.0101717.\r\nInstantiating context...\r\nIt took 00:00:00.0139057.<\/code><\/pre>\nA peek at the query pipeline<\/h2>\n
EF Core performs quite a bit of work to get from your application to returning the first result of the first query your application processes. Let’s break down the following two statements and go “behind the scenes” to see what happens.<\/p>\n
using var myContext = new MyContext();\r\nvar results = myContext.MyWidgets.ToList();<\/code><\/pre>\nDbContext instantiation<\/h3>\n
The first step is creating an instance of the context. The first time a
DbContext<\/code> is created, EF Core will create and compile delegates to set the table properties you expose by usingDbSet<Entity><\/code>. This simply creates the delegates to set the properties so you can query them right away.<\/p>\nPerformance tip:<\/strong> you can avoid the overhead of
DbSet<\/code> initialization by using an alternate approach such as thecontext.Set<Entity>()<\/code> API call.<\/p><\/blockquote>\nDbContext (lazy) initialization<\/h3>\n
After the
DbContext<\/code> is created, EF Core “goes to sleep” until you use it. The first time you use a context by accessing one of its APIs (such as navigating an entity and returning results), the context is initialized. This will run theOnConfiguring<\/code> method to establish the proper provider<\/a> and database connections as well as other settings. For example, this is the perfect place to use the simple logging<\/a> feature by calling the newLogTo<\/code> extension on the options builder<\/a>.<\/p>\nService provider<\/h3>\n
EF Core uses a service-based architecture and has an internal dependency injection framework. This provider is built internally but is designed to work with external DI solutions such as the service provider in ASP.NET Core<\/a>.<\/p>\n
Performance tip:<\/strong> much of the overhead described so far can be mitigated by using context pooling<\/a>. This enables a pool of reusable context instances that are already initialized.<\/p><\/blockquote>\n
Model building<\/h3>\n
To understand how a domain object (C# class) relates to the tables and relationships in the database, EF Core builds an internal model that represents all the types, properties, constraints, and relationships that it finds in your
DbContext<\/code>. This is a metadata model and includes the call toOnModelCreating<\/code> that can be overridden to provide fluent configuration of the model.<\/p>\nQuery compilation<\/h3>\n
A major reason why developers use EF Core is its ability to parse Language Integrated Queries (LINQ) into the database dialect. This is an advanced stage because it involves traversing a potentially complex expression tree and translating it into SQL. Something trivial like a projection:<\/p>\n
var projection = myQuery.Select(obj => new { id = obj.EntityId, name = obj.Identifier });<\/code><\/pre>\nSeems easy enough to translate:<\/p>\n
SELECT EntityId, Identifier FROM ...<\/code><\/pre>\nBut what about something more complicated, like this?<\/p>\n
var pairs = (from a1 in context.Attendees\r\n from a2 in context.Attendees\r\n where a1.Id != a2.Id\r\n select new\r\n {\r\n a1 = a1.Id,\r\n a1LastName = a1.LastName,\r\n a1FirstName = a1.FirstName,\r\n a2 = a2.Id,\r\n a2LastName = a2.LastName,\r\n a2FirstName = a2.FirstName,\r\n sessionCount = \r\n a1.Sessions.Select(s => s.Id)\r\n .Intersect(a2.Sessions.Select(s => s.Id)).Count()\r\n }).OrderByDescending(shared => shared.sessionCount)\r\n .Take(5);<\/code><\/pre>\nThis is ultimately parsed into native SQL, intersection and all. The first time that EF Core encounters a query, it parses the query to determine which parts are dynamic. It then compiles the static parts of the query and parameterizes the dynamic aspects to expedite translation into SQL by using a SQL template.<\/p>\n
Run the query<\/h3>\n
Finally! The query is now run. To avoid the overhead of performing these steps every time, EF Core caches the delegates for
DbSet<\/code> properties, the internal service provider, the constructed model, and the compiled query. This results in much faster performance after the queries are successfully run the first time.<\/p>\nYou can visualize these steps using the following diagram (note the cache boxes have strike-through to show they are disabled for our benchmark tests):<\/p>\n
![\"EF](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2021\/06\/efcompiledsteps.jpg\")
<\/p>\nAlthough most of the pipeline is already streamlined, model compilation was an area we knew could improve.<\/p>\n
A note on source generators.<\/strong> The approach the team chose is to provide a command that generates the source code files that you can then incorporate into your project to build the compiled model. We are often asked why we didn’t choose source generators<\/a>. The answer is that source generators run as user code inside the Visual Studio process. EF Core must build and run the context to obtain information about the model. If an exception is thrown as part of the process, this could potentially force Visual Studio to hang or crash.<\/p><\/blockquote>\n
As with most technology, compiled models do have trade-offs. Let’s look at the pros and cons.<\/p>\n
Pros and cons<\/h2>\n
The pros should be clear. As your model grows larger, your startup time remains fast. Here is a comparison of startup time between compiled and non-compiled models based on the size of the model.<\/p>\n
![\"Startup](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2021\/06\/compiledmodels.png\")
<\/p>\nHere are some cons to consider:<\/p>\n
- \n
- Global query filters<\/a> are not supported.<\/li>\n
- Lazy loading proxies<\/a> are not supported.<\/li>\n
- Change tracking proxies<\/a> are not supported.<\/li>\n
- Custom IModelCacheKeyFactory<\/a> implementations are not supported.<\/li>\n
- The model must be manually synchronized by regenerating it any time the model definition or configuration change.<\/li>\n<\/ul>\n
Tip:<\/strong> if supporting any of these features is critical to your success, please find the issue<\/a> and upvote it or add your comments and thoughts, or file a new issue<\/a> to let us know.<\/p><\/blockquote>\n
Now you’ve learned the background. How do you get started?<\/p>\n
In conclusion<\/h2>\n
To start using compiled models today, reap the performance benefits and have the opportunity to provide us with feedback before we release the final EF Core 6.0 version, start by grabbing the latest preview (instructions are below) and installing the latest EF Core CLI<\/a>. The new tool command looks like this (all parameters are optional):<\/p>\n
dotnet ef dbcontext optimize -c MyContext -o MyFolder -n My.Namespace <\/code><\/pre>\nInside the NuGet package manager console you can use this:<\/p>\n
Optimize-DbContext -Context MyContext -OutputDir MyFolder -Namespace My.Namespace<\/code><\/pre>\nThe tool will instruct you to add a line like this to your options configuration:<\/p>\n
opts.UseModel(My.Namespace.MyContextModel.Instance);<\/code><\/pre>\nWe hope you benefit from this new feature and can provide us with early feedback. Check out the EF Core 6.0 plan<\/a>. In addition to other work, the team has prioritized a number of Azure Cosmos DB provider features<\/a>. Please upvote the features that are important to you and share any feedback you may have! Other features in the preview 5 release will be posted in EF Core 6.0 What’s New<\/a>.<\/p>\n
How to get EF Core 6.0 previews<\/h2>\n
EF Core is distributed exclusively as a set of NuGet packages. For example, to add the SQL Server provider to your project, you can use the following command using the dotnet tool:<\/p>\n
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 6.0.0-preview.5.21301.9<\/code><\/pre>\nThis following table links to the preview 5 versions of the EF Core packages and describes what they are used for.<\/p>\n
- Lazy loading proxies<\/a> are not supported.<\/li>\n
- Global query filters<\/a> are not supported.<\/li>\n
![\"ajcvickers\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2020\/03\/efteam_ajcvickers.jpeg\")
\nArthur Vickers<\/a><\/td>\n![\"AndriySvyryd\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2020\/03\/efteam_AndriySvyryd.jpeg\")
\nAndriy Svyryd<\/a><\/td>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2020\/03\/efteam_bricelam.jpeg\")
\nBrice Lambson<\/a><\/td>\n![\"JeremyLikness\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2020\/03\/efteam_JeremyLikness.jpeg\")
\nJeremy Likness<\/a><\/td>\n<\/tr>\n![\"maumar\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2020\/03\/efteam_maumar.jpeg\")
\nMaurycy Markowski<\/a><\/td>\n![\"roji\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2020\/03\/efteam_roji-1-300x300.png\")
\nShay Rojansky<\/a><\/td>\n![\"smitpatel\"](\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2020\/03\/efteam_smitpatel.png\")
\nSmit Patel<\/a><\/td>\n