-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Simplify verify throw and remove unnecessary usings #6992
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When calculating a value to see if we can do a type of comparison, store that value so we don't have to calculate it again. Use Try*Evaluate instead of Can*Evaluate and *Evaluate.
Removes all *Evaluate and Can*Evaluate except in OperatorExpressionNodes, for which CanBoolEvaluate always returns true, so using a simple BoolEvaluate makes sense. Note that for the NumericComparisonExpressionNode, we could save a tiny amount of time by only calling TryEvaluate when it's actually used (and using if/else as before), but that would since something can be both a number and a version, that would mean we would have to check both regardless of what we had previously found, which means it would be noticeably messier for (probably) very little perf gain, so I opted against that. Switch statements are so pretty 🙂
Apparently that's the best supported way
I tested once with and once without this change, and with this change, Evaluate was 3% faster...that sounds noisy, but I'll still take it.
These statements only do anything if the condition is false, but they evaluate their arguments either way. These do nontrivial work when evaluating their arguments, so figure out if we should skip it early. This is specifically tuned to BoolEvaluate (part of evaluating conditions)
Slightly reduce other work done
f521fa4
to
fd02288
Compare
Rather than checking whether false is false.
fd02288
to
f13ad04
Compare
These statements only do anything if the condition is false, but they evaluate their arguments either way. These do nontrivial work when evaluating their arguments, so figure out if we should skip it early. This is specifically tuned to BoolEvaluate (part of evaluating conditions)
Slightly reduce other work done
Rather than checking whether false is false.
f13ad04
to
f81a256
Compare
…uild into simplify-verifyThrow
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 has a little random cleanup plus moving the condition outside VerifyThrow calls if simply calling the method would do a nontrivial amount of work. The fourth commit switches VerifyThrow* to Throw* as appropriate.
I haven't measured the performance impact. The first and fourth commits should have ~0 impact, though technically the fourth commit makes it slightly faster in the failure case (by one branch). The third helps us avoid a couple small allocations. The second lets us avoid a nontrivial amount of work in an extremely common case, so if this has a positive perf impact, I would suspect that commit.
It should be easiest to look at this commit-by-commit.