-
Notifications
You must be signed in to change notification settings - Fork 15.6k
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
C#: Optimize parsing of some primitive and wrapper types #6843
C#: Optimize parsing of some primitive and wrapper types #6843
Conversation
I'll review the C# side, I'd like @gerben-s to check the correctness of the wrapper parsing optimizations. |
6bb4109
to
2cd2abe
Compare
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.
What about the other wrappers? fixed32, int32 etc...
All primitive wrapper types implemented. |
2cd2abe
to
2ac8946
Compare
@gerben-s PTAL |
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.
Overall I think that the code contains redundancies and could be factored better in time. But it's an excellent change to improve speed.
int shift = 0; | ||
ulong result = 0; | ||
while (shift < 64) | ||
if (bufferPos + 10 <= bufferSize) |
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.
I think ReadRawVarint32 needs a similar change
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.
ReadRawVarint32
already appears optimized I think?
9093bd9
to
d22eade
Compare
The "TimerTest" benchmark shows the following improvement: Before:
After:
|
} | ||
else | ||
{ | ||
var bytes = new byte[8]; |
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.
nit: not that important because we don't really have users on big endian I think, but can we avoid the allocation?
Unfortunately stackalloc is not available because as currently the LangVersion is set to 6.
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.
Agreed stackallow would be much better here.
Not that I'm suggesting changing this now, but why are you still on C# 6?
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.
(complicated story, but basically we had an internal user that could only use C# 6 due to using Unity. I believe that's no longer a problem).
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.
If this dependency is no longer true, then can we start using stackalloc and Span and such niceties?
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.
LGTM with one minor nit.
Merging (and will backport to v3.10.x) |
Benchmark on my Windows 10 machine.
Before:
After: