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
Current results show that composing Expression Tree may take significant amount of time even compare to compilation of expression. It happens because Expression validates its child nodes and wrapped operations. But in case you do it on your own, that seems like a double work.
Introducing lightweight DryExpression may improve performance (and probably memory utilization) in such case. It may be also designed the way to include normal Expressions as children. So the implementation may start with sub-set of expressions, and DryExpressionCompiler may fallback to FastExpressionCompiler for the rest.
Current results for creating simple DryExpression.New vs Expression.New:
The text was updated successfully, but these errors were encountered:
dadhi
changed the title
Use lightweight DryExpression to improve performance of manually created expression
Use lightweight replacement for Expression to improve performance of manually created expression
Jun 22, 2017
For service with two dependencies, created with ExpressionInfo instead of Expression and then compiled is ~2x faster (at the moment). Hey, expected 25% improvements but not as much!
The final results
Benchmark of Creating and Compiling expression
() => new X(new A(), new B())
Comparing classic
Expression
Expression.Lambda(Expression.New(_xCtor, Expression.New(_aCtor), Expression.New(_bCtor)))
vs lightweight
ExpressionInfo
:ExpressionInfo.Lambda(ExpressionInfo.New(_xCtor, ExpressionInfo.New(_aCtor), ExpressionInfo.New(_bCtor)))
Supported lightweight
ExpressionInfo
'sExpressionInfo.Lambda
ExpressionInfo.Parameter
ExpressionInfo.Constant
ExpressionInfo.Call
ExpressionInfo.Property
ExpressionInfo.Field
The rest is for the later.
Old info
Current results show that composing Expression Tree may take significant amount of time even compare to compilation of expression. It happens because Expression validates its child nodes and wrapped operations. But in case you do it on your own, that seems like a double work.
Introducing lightweight
DryExpression
may improve performance (and probably memory utilization) in such case. It may be also designed the way to include normal Expressions as children. So the implementation may start with sub-set of expressions, andDryExpressionCompiler
may fallback toFastExpressionCompiler
for the rest.Current results for creating simple
DryExpression.New
vsExpression.New
:The text was updated successfully, but these errors were encountered: