Database Reference
In-Depth Information
Following is the output of the code in Listing 13-20:
Not Compiled #0: 10014
Not Compiled #1: 5004
Not Compiled #2: 5178
Not Compiled #3: 7624
Not Compiled #4: 4839
Not Compiled #5: 5017
Not Compiled #6: 4864
Not Compiled #7: 5090
Not Compiled #8: 4499
Not Compiled #9: 6942
Average ticks without compiling: 5907
Compiled #0: 3458
Compiled #1: 1524
Compiled #2: 1320
Compiled #3: 1283
Compiled #4: 1202
Compiled #5: 1145
Compiled #6: 1075
Compiled #7: 1104
Compiled #8: 1081
Compiled #9: 1084
Average ticks with compiling: 1427
How It Works
When you execute a LINQ query, Entity Framework builds an expression tree object for the query, which is then
converted, or compiled, into an internal command tree. This internal command tree is passed to the database
provider to be converted into the appropriate database commands (typically SQL). The cost of converting an
expression tree can be relatively expensive depending on the complexity of the query and the underlying model.
Models with deep inheritance or horizontal splitting introduce enough complexity in the conversion process that
the compile time may become significant relative to the actual query execution time. However, in Version 5 of the
Entity Framework, automatic query caching for LINQ queries was introduced. You can get an idea of the performance
benefits of this feature by examining the results of Listing 13-20.
Additionally, as shown in Listing 13-20, you can disable the auto-compiling features by dropping down from the
DbContext object into the underlying ObjectContext object, obtaining a reference to the entity object and setting its
EnablePlanCaching property to false.
To track each compiled query, Entity Framework walks the nodes of the query expression tree and creates a
hash, which becomes the key for that compiled query in the underlying query cache. For each subsequent call, Entity
Framework will attempt to locate the hash key from the cache, eliminating the overhead cost of the query translation
process. It's important to note that the cached query plan is independent of the context object, instead being tied
to the AppDomain of the application, meaning that the cached query is available to all instances of a given Entity
Framework context object.
