EF 4.2 impact of auto-compiled linq queries
From MSDN magazine:
The June CTP supports a new feature called the Auto-Compiled LINQ Queries, which lets every LINQ to Entities query you execute automatically get compiled and placed in the EF query cache. Every time you run the query subsequently, the EF wil开发者_StackOverflowl find it in its query cache and won’t have to go through the whole compilation process again.
I thought it was recommended only to compile queries that you run frequently because of the time it takes to compile a query? So is the compilation process improved that it's recommended to do this?
Thanks.
There are two articles (ADO.NET team blog, Julie Lerman's blog) about auto compiled queries which will give you some idea about performance. What are main points of auto compiled queries and performance:
- The feature can be turned off globally
- The feature can be controlled per ObjectQuery (but there are currently some problems)
- Without too much knowledge of internals I guess the feature should be faster even for queries used rarely - it will only increase memory consumption. If you have query compiled every time, the expression tree must be every time traversed and interpreted as parametrized SQL (I checked once internal implementation and it really follows some rules of building compiler / interpreter). I did some very quick check of this new cache implementation and it looks like auto compiling will internally store prototype of DbCommand used to execute the query. So the only thing which must be done next time the query is called is traversal of the expression tree and computing its hash to find that cached DbCommand and crate its clone which will be executed.
But those are mostly my assumptions so only the real world usage will show if it is really true.
精彩评论