- Notifications
You must be signed in to change notification settings - Fork5.2k
Improve perf of Utf8Parser.TryParse for int64 and uint64#52423
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
ghost commentedMay 7, 2021
Tagging subscribers to this area:@tannergooding,@pgovind,@GrabYourPitchforks Issue DetailsSomewhat inspired by investigating#52314 and seeing a little bit of low-hanging fruit that we can address. Perf results (basically from runningthis benchmark with some additional inputs): | Method | Toolchain | value | Mean Error | StdDev | Ratio | Some of the benchmarks were going a bit screwy on my machine, so I basically ran them one at a time and concatenated all of the results into a single table. Not sure what was up with my environment. The tl;dr is that this shouldn't have any worse perf than the existing code, and the total codegen ends up being448 bytes smaller compared to baseline across the two methods.
|
| if((uint)firstChar==unchecked((uint)('-'-'0'))) | ||
| { | ||
| sign--;// set to -1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| sign--;// set to -1 | |
| sign=-1; |
Make it explicit?
The JIT will emit code likemov rax, 0xffffffffffffffff anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The JIT emitsdec rax for this scenario. I think it doesn't propagate the "if (idx != 0) { FAIL; }" assertion above for some reason.
I can setsign = -1; explicitly, but it does increase the codegen by 7 - 8 bytes. Maybe it's too much of a microoptimization to worry about and the cleaner code is better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
So I'd keep it as is. Thanks for the info.
| // If sign = -1, this becomes value = (parsedValue ^ -1) - (-1) = ~parsedValue + 1 = -parsedValue | ||
| bytesConsumed=idx; | ||
| value=((long)parsedValue^sign)-sign; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
🚀
The same could be done to other types too (like int32 above, etc.)?
stephentoub left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thanks. Are there any similar gains to be had in {u}long.TryParse?
jeffhandley commentedJun 12, 2021
@GrabYourPitchforks Is this ready to merge? |
jeffhandley commentedJul 3, 2021
Ping on this,@GrabYourPitchforks. It would be great to get this in for Preview 7. |
GrabYourPitchforks commentedJul 12, 2021
I investigated the framework's other parsing routines, but they have a bit more complexity, needing to handle whitespace and trailing nulls. Opened#55541 so we don't lose track of this. |
Uh oh!
There was an error while loading.Please reload this page.
Somewhat inspired by investigating#52314 and seeing a little bit of low-hanging fruit that we can address.
Perf results (basically from runningthis benchmark with some additional inputs):
Some of the benchmarks were going a bit screwy on my machine, so I basically ran them one at a time and concatenated all of the results into a single table. Not sure what was up with my environment.
The tl;dr is that this shouldn't have any worse perf than the existing code, and the total codegen ends up being448 bytes smaller (on x64) compared to baseline across the two methods.