Description
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.
public class IncludeExpressionInfo
{
public LambdaExpression LambdaExpression { get; }
public Type EntityType { get; }
public Type PropertyType { get; }
public Type? PreviousPropertyType { get; }
public IncludeTypeEnum Type { get; }
}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,PropertyTypeandPreviousPropertyTypeare removed fromIncludeExpressionInfo.