Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This brings some performance enhancements to the way we resolve
Field
,Fields
andPropertyName
when these are instantiated using anExpression
. E.g if you doq.Term<Project>(p=>p.Name, "value")
We were visiting the expression multiple times
sane
keyThis PR
Combines the comparison vistor/tostring visitor/caching visitor into one. We no longer rely on
Expression.ToString()
and since we only need to deal with a certain type of expression our tostring performance better then the BCL one.Then if its we pass it off the
FieldExpressionVisitor
if not in local cache already. While writing this I wonder ifFieldExpressionVisitor
could reuse the stack from our newToStringVisitor
. Will follow up in a comment.The benchmark compares:
Expression<Func<T, object>>.ToString()
asBoxed Expression
Expression<Func<T, TValue>>.ToString()
asUnboxed Expression
FieldInferrer.Resolve(Expression<Func<T, object>>)
asField Resolver
FieldInferrer.Resolve(Expression<Func<T, TValue>>)
asField Resolver Unboxed
, only available on last benchmarkbefore
after