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
gerben-s
left a comment
There was a problem hiding this comment.
What about the other wrappers? fixed32, int32 etc...
|
All primitive wrapper types implemented. |
2cd2abe to
2ac8946
Compare
|
@gerben-s PTAL |
gerben-s
left a comment
There was a problem hiding this comment.
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.
I think ReadRawVarint32 needs a similar change
There was a problem hiding this comment.
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.
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.
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.
(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.
If this dependency is no longer true, then can we start using stackalloc and Span and such niceties?
jtattermusch
left a comment
There was a problem hiding this comment.
LGTM with one minor nit.
|
Merging (and will backport to v3.10.x) |
Benchmark on my Windows 10 machine.
Before:
After: