During a customer test of the new auto-compile feature of EF 5 (prerelease build) was tested and compared with the implementation the CAT team built for the custoemr using a wrapping provider.
What we discovered was promising. Performance with the EF autocompile was close to that of the wrapping provider. This is great because previous tests and subsequent code profiling/refinement showed that the EF auto-compile was once much slower.
We implemented data caching with the new EF 5.0 and discovered that this caching was 2x slower using the EF provider. The reason is simple, we generated a hash of the T-SQL as opposed to the expression tree.
Thus, if EF allowed the user to pass in their own hashing delegate for autocompile then this same hash could be used for the data caching as well. Or
Provide a mechanism upon which extract the hash key from the auto-compile whereby the user could perform a data cache lookup in advance to running the query.
What we discovered was promising. Performance with the EF autocompile was close to that of the wrapping provider. This is great because previous tests and subsequent code profiling/refinement showed that the EF auto-compile was once much slower.
We implemented data caching with the new EF 5.0 and discovered that this caching was 2x slower using the EF provider. The reason is simple, we generated a hash of the T-SQL as opposed to the expression tree.
Thus, if EF allowed the user to pass in their own hashing delegate for autocompile then this same hash could be used for the data caching as well. Or
Provide a mechanism upon which extract the hash key from the auto-compile whereby the user could perform a data cache lookup in advance to running the query.