Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update expression constructs. Reduce size. #426

Closed
Tracked by #427
fiseni opened this issue Nov 9, 2024 · 0 comments · Fixed by #448
Closed
Tracked by #427

Update expression constructs. Reduce size. #426

fiseni opened this issue Nov 9, 2024 · 0 comments · Fixed by #448
Assignees

Comments

@fiseni
Copy link
Collaborator

fiseni commented Nov 9, 2024

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, PropertyType and PreviousPropertyType are removed from IncludeExpressionInfo.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant