Prompted by Roger Jennings' post Entity Framework Instantiation Times with a 120-Table Database, but with limited time to do a thorough investigation, I did a quick trial this morning comparing AdventureWorksLT with it's dozen tables/views to another model with about 400.
There are a few up-front costs for querying in Entity Framework. Query compilation is one and another biggie is loading the model into the application cache. Once the model is loaded, it remains in the applications cache and under normal circumstances, won't need to load again. EF only loads the model pieces as needed. In default scenarios, the conceptual layer is first loaded when ObjectContext is instantiated; the store and mapping layers are loaded the first time a query needs to be compiled.
I am starting the stopwatch prior to the instantiation of each context and stopping when the results have been iterated through completely. I ran the tests numerous times with consistent results.
| First query in application | Same query in a completely new objectContext, which benefits from the model already being loaded | |
| AdventureWorksLT | 1512 ms | 36 ms |
| 400+ entity model | 4411ms | 46ms |
The entity queried in the second test is much wider (many more properties) than the entity queried in the AdventureWorks test. The effort of materializing the app. 200 large objects understandably great than materializing the app. 400 smaller objects from AdventureWorks, so I'm not concerned abut the 10 ms difference there.
My recommendation is to preload the model before you need to do any queries. You can manually load a metadataworkspace or use this lame trick (Quick Trick for forcing MetadataWorkspace ItemCollections to load) to force it to load early in your application life-cycle.
I've gotten some interesting comments on yesterday's post about building models from very large databases: Entity Framework Designer and Large Databases
