Repository navigation
perf: mark the writer noalias in the writing helpers - #51
Merged
Merged
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 55 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
lalinsky
added this pull request to stack #52
October 13, 2026 08:40
The writer's buffer is a []u8, and a byte store may alias anything,
including the writer struct itself. So after every byte written into the
buffer, the compiler has to reload end, buffer.ptr and buffer.len before
the next write, and a run of small writes becomes a chain of dependent
loads and stores through memory.
noalias on writeByte, writeAll, packHeaderAndInt and packStringLiteral
tells it that the stores into the buffer leave the writer alone. These
are leaves that never hand the writer to other code, so the promise is
easy to keep. The functions that do pass the writer on, such as packAny,
which can call a user's msgpackWrite, are left as they are.
Cycles per encode, ReleaseFast, perf stat:
case before after
order 343 257 -25% struct with 8 fields, 4 nested items
ints 8864 8939 flat array of 1000 mixed-size u32
The instruction count barely moves (804 -> 786 for order); the saving is
in the dependency chain. The int array is one call per element, so there
is no run of writes for it to help.
lalinsky
force-pushed
the
encode-noalias
branch
from
October 13, 2026 08:46
9ee8387 to
00ac8d0
Compare
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
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.
Stacked on #50.
The writer's buffer is a
[]u8, and a byte store may alias anything, including theWriterstruct itself. So after every write into the buffer, the compiler has to reloadend,buffer.ptrandbuffer.lenbefore the next write. A run of small writes becomes a chain of dependent loads and stores through memory.noaliasonwriteByte,writeAll,packHeaderAndIntandpackStringLiteraltells it that the buffer stores leave the writer alone. These are leaves that never hand the writer to other code, so the promise is easy to keep. Functions that pass the writer on, such aspackAny, which can call a user'smsgpackWrite, are left alone.Cycles per encode, same setup as #50:
u32)The instruction count barely moves (804 → 786 for order); the saving is the dependency chain. The int array is one call per element, so there's no run of writes for it to help.
Tests pass on 0.16 and 0.17, and in ReleaseFast.