You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently produce a shaper for each query we compile; since as many queries end up having identical shapers, we can have a cache which allows queries to reuse shapers. This would help reduce binary size for NativeAOT, and would also help regular JIT application performance as ew need to compile less shapers at runtime.
This is basically about figuring out the correct, comprehensive cache key for shapers, and implementing the caching.
Note that we also have #32923, which is about reusing materializers across queries (with materializers being the narrower piece of code that materializes an instance from DbDataReader, and therefore doesn't care about tracking/no-tracking, split query....). Both caches can be done independently.
The text was updated successfully, but these errors were encountered:
We currently produce a shaper for each query we compile; since as many queries end up having identical shapers, we can have a cache which allows queries to reuse shapers. This would help reduce binary size for NativeAOT, and would also help regular JIT application performance as ew need to compile less shapers at runtime.
This is basically about figuring out the correct, comprehensive cache key for shapers, and implementing the caching.
Note that we also have #32923, which is about reusing materializers across queries (with materializers being the narrower piece of code that materializes an instance from DbDataReader, and therefore doesn't care about tracking/no-tracking, split query....). Both caches can be done independently.
The text was updated successfully, but these errors were encountered: