url: create URLSearchParams collision map lazily - #65801
Open
RomainLanz wants to merge 1 commit into
Open
Conversation
Collaborator
|
Review requested:
|
Object property keys are already unique unless USVString normalization changes a key. Avoid allocating and updating a SafeMap for ordinary record keys. Create and backfill it when normalization first changes a key. This improves object construction by 10% to 25% in the measured cases and reduces allocation by about 31% for a ten-property record. Assisted-by: Amp Signed-off-by: Romain Lanz <romain.lanz@pm.me>
RomainLanz
force-pushed
the
perf/urlsearchparams-lazy-map
branch
from
September 4, 2026 19:06
3f30ad2 to
2fb7b16
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #65801 +/- ##
==========================================
- Coverage 90.17% 90.13% -0.04%
==========================================
Files 769 769
Lines 261448 261638 +190
Branches 49674 49673 -1
==========================================
+ Hits 235759 235831 +72
- Misses 16736 16812 +76
- Partials 8953 8995 +42
🚀 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
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.
Note
AI assistance was used to investigate this change and draft parts of the
implementation, tests, benchmarks, and PR description. I reviewed and
verified the final changes and benchmark results.
Hey! 👋
new URLSearchParams(record)currently creates and updates aSafeMapfor every record.Most property names do not need this map. JavaScript object keys are already unique, so no collision is possible while
toUSVString(key)leaves the key unchanged.A map is only needed when a property name contains malformed UTF-16.
toUSVString()replaces the invalid part with�(U+FFFD), which can make two different property names identical:This change appends entries directly while keys remain unchanged. When the first key changes during conversion, it creates the
SafeMap, adds the entries already processed, and continues with the existing collision handling. The later value still replaces the earlier one without changing its position.A test covers a collision occurring after regular keys have already been processed.
Benchmark
Node v27.0.0-pre, V8 14.6.202.34-node.29, 15 runs with 4 million constructions per run:
For ten-property records, a separate GC diagnostic measured:
A conversion-heavy TCP loopback benchmark improved from 857k to 1.14M frames/s (+33%). This only demonstrates the cumulative effect when
URLSearchParamsconstruction is hot; it is not a general TCP performance claim.The malformed-key fallback measured 544.4 → 550.9 ns/op, around 1.2% slower and within the observed noise. This rare path now pays for creating and backfilling the map.
Tests
The focused constructor test, the URLSearchParams fast-path test, and the URL
WPT suite pass.