Repository navigation
v1.9.1 remove per-encode allocations from varint and field iteration - #23
Merged
Merged
Conversation
Varint UInt/Int writes now pass Smi-range int32 values to the writer instead of out-of-range doubles that V8 boxes, and object fields are iterated with an indexed loop instead of for...of. Output bytes are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
reececomo
marked this pull request as ready for review
November 9, 2026 02:11
reececomo
changed the title
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.
encode()no longer allocates for varint fields or field iteration, and the output bytes are unchanged.More details
Double and float fields never allocated. I verified this on Node 20 and 24, with and without TurboFan. The allocations came from two other places:
for...ofloop over fields in_$writeallocated about 2.5 KB per encode before TurboFan optimized it. It is now an indexed loop.value + 0xc0000000falls outside the Smi range. This cost about 16 B per field. The writes now pass Smi-range int32 values, and the low 32 bits are written as two uint16 values.Allocation per encode, measured with
heapUsedon a nested schema with 45 float fields:--max-opt=0)The remaining ~96 B is the
subarray()view returned byencode(data, false). I left it alone because avoiding it would change the identity of the returned view.New tests check the float64 bytes for special values (NaN, ±Infinity, -0, subnormals and
MAX_VALUE). They also compare varint bytes against the previous formulas across about 2,400 values. All 120 tests pass and lint is clean. This bumps the version to 1.9.1 and rebuildsdist, so merging publishes it.🤖 Generated with Claude Code