Repository navigation
Encoder: write the key of a map of strings by the opcode of the map entry - #641
Merged
Merged
Conversation
An entry of a map was four opcodes: OpMapKey gave the key to the opcode of the key, which wrote it, OpMapValue gave the value to the opcode of the value, which wrote it, and OpMapKey again. For a map whose key is a plain string, which most of the maps are, OpMapKey writes the key itself and gives the value to its opcode: two dispatches per entry are saved. The header begins the first entry the same way, by falling through to OpMapKey with the next opcode and the flags of one. A key of another kind is still written by its opcode, followed by OpMapValue, so that the code of the VM stays as it was for them. arm64: MapInterface 217 -> 214 ns sorted, 183 -> 176 ns unordered. Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #641 +/- ##
==========================================
+ Coverage 81.69% 81.74% +0.04%
==========================================
Files 59 59
Lines 10745 10774 +29
==========================================
+ Hits 8778 8807 +29
Misses 1967 1967 🚀 New features to boost your workflow:
|
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
An entry of a map was four opcodes:
OpMapKeygave the key to the opcode of the key, which wrote it,OpMapValuegave the value to the opcode of the value, which wrote it, andOpMapKeyagain. For a map whose key is a plain string (not a pointer, notjson.Number, no marshaler),OpMapKeywrites the key itself and gives the value to its opcode: two dispatches per entry are saved. The header begins the first entry the same way, by falling through toOpMapKeywith the next opcode and the flags of one.A key of another kind is still written by its opcode, followed by
OpMapValue, so the VM's code for them is unchanged.TestEncodeMapKeyscompares maps of every kind of a key, nested and in structs, sorted and with an indent, against encoding/json;TestEncodeMapUnorderedchecks the unsorted option.Results (CI)
Encode_MapInterfacevs master: -4.6% (EPYC 9V74 runner), -5.9% (A/B against the parent commit on the EPYC 9V45 runner). The other benchmarks are within the noise (the A/B shows LargeStructCached +6% on one runner and +0.7% on the other; the struct opcodes are unchanged).Against sonic on the EPYC 9V45, with
SONIC_MAX_INLINE_DEPTH=10:UnorderedMapvs sonic default)With this, every benchmark of the comparison is at or below sonic's best configuration on that runner (LargeStructCached +3%, within its noise).
Test plan
go test ./...on arm64 and amd64,make lint🤖 Generated with Claude Code