Reduce string encoding/decoding in MessagePackFormatter #594
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.
Several strings are very common in JSON-RPC. Rather than encode/decode them repeatedly, allocating new strings each time we decode, we instead use pre-encoded bytes and recognize the encoded bytes without decoding them.
The techniques used here come from MessagePack's own mpc-tool code output. So even though we're using MessagePack's "internal" namespace, it needs to be stable within a major version to keep mpc generated code working.
I recognize that this compromises readability, but perf traces indicate that the decoding time and allocation costs are significant, so I believe it is justified. I define constants and add code comments to help explain it.
Also note (because I only learned this recently) that in C# the syntax below produces very efficient code. It never allocates an array -- ever. Not even once. Read the IL yourself. This syntax leads the C# compiler to generate code that initializes the
ReadOnlySpan<byte>
to point directly into the binary of the loaded assembly itself to get at the bytes in the compiled binary.I did not optimize every single formatter in the
MessagePackFormatter.cs
file. Just the hot path ones. We can optimize the error formatter if that becomes important.