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 keep the expressions in separate containers in the specification. The theme of version 9 is to reduce the allocations as much as possible. In that spirit, we may reduce the size of these constructs.
The WhereExpressionInfo, OrderExpressionInfo, and SearchExpressionInfo contain the delegate (the compiled expression) used in the in-memory evaluators. The state is kept as Lazy<Func<>>, and the expression is compiled on first use. Technically, this is correct, but the overhead of the Lazy instance is 32 bytes. Considering that the majority of the users do not use in-memory evaluations at all, this is an unnecessary price to pay. We should optimize the library for the "common" usage.
The specifications are not intended to be thread-safe. So, perhaps we should avoid the Lazy, keep the state directly as nullable Func<>, and initialize it on the first access. The worst that may happen is that the expression is compiled multiple times (if anyone uses it concurrently).
In addition to this, IncludeExpressionInfo has the following state.
The EntityType is already available as the T generic parameter, so we don't need to store it. The PropertyType is already contained in the lambda expression, it's the same as LambdaExpression.ReturnType. The expressions are applied sequentially in the evaluator, so the PreviousPropertyType can be easily deduced during the evaluation. By removing these properties we'll save 24 bytes per instance.
Breaking Changes:
The EntityType, PropertyType and PreviousPropertyType are removed from IncludeExpressionInfo.
The text was updated successfully, but these errors were encountered:
We keep the expressions in separate containers in the specification. The theme of version 9 is to reduce the allocations as much as possible. In that spirit, we may reduce the size of these constructs.
The
WhereExpressionInfo
,OrderExpressionInfo
, andSearchExpressionInfo
contain the delegate (the compiled expression) used in the in-memory evaluators. The state is kept asLazy<Func<>>
, and the expression is compiled on first use. Technically, this is correct, but the overhead of theLazy
instance is 32 bytes. Considering that the majority of the users do not use in-memory evaluations at all, this is an unnecessary price to pay. We should optimize the library for the "common" usage.The specifications are not intended to be thread-safe. So, perhaps we should avoid the Lazy, keep the state directly as nullable
Func<>
, and initialize it on the first access. The worst that may happen is that the expression is compiled multiple times (if anyone uses it concurrently).In addition to this,
IncludeExpressionInfo
has the following state.The
EntityType
is already available as theT
generic parameter, so we don't need to store it. ThePropertyType
is already contained in the lambda expression, it's the same asLambdaExpression.ReturnType
. The expressions are applied sequentially in the evaluator, so thePreviousPropertyType
can be easily deduced during the evaluation. By removing these properties we'll save 24 bytes per instance.Breaking Changes:
EntityType
,PropertyType
andPreviousPropertyType
are removed fromIncludeExpressionInfo
.The text was updated successfully, but these errors were encountered: