[Perf]: ~1.9x faster parse via fast-paths and manual scanning#552
[Perf]: ~1.9x faster parse via fast-paths and manual scanning#552homanp wants to merge 2 commits into
Conversation
ljharb
left a comment
There was a problem hiding this comment.
This will need a rebase; it conflicts with some bugfixes i merged.
| if (cleanStr.indexOf('%5') !== -1) { | ||
| cleanStr = cleanStr.replace(/%5B/gi, '[').replace(/%5D/gi, ']'); | ||
| } |
There was a problem hiding this comment.
i'm surprised "indexOf + 2 replaces" being slower doesn't outweigh the benefit of the other branch being "indexOf instead of 2 replaced". it might be a good idea to do each change in a separate commit, and put the benchmark results in each commit message.
There was a problem hiding this comment.
Ageee, Will make it clearer. Ty for feedback.
…parts Hoist decoder/defaultDecoder lookups out of the per-part loop. Check whether each part actually contains '%' or '+' before calling the decoder; plain ASCII key=value pairs are sliced directly without entering the decode path. Benchmark (weighted ops/sec): 540,502 → 696,526 (+28.9%) flat: 745,039 → 1,010,337 nested: 394,463 → 481,302 arrays: 356,643 → 534,676 encoded: 846,351 → 859,280 search: 332,500 → 492,732
When a key has no '[' (and no '.' when allowDots is set), assign directly instead of going through parseKeys/splitKeyIntoSegments/ parseObject/merge. Also track whether any key needed the full path to skip the compact() pass when it is unnecessary. Benchmark (weighted ops/sec): 696,526 → 861,226 (+23.6%) flat: 1,010,337 → 1,430,967 nested: 481,302 → 461,549 arrays: 534,676 → 536,818 encoded: 859,280 → 1,067,296 search: 492,732 → 580,142
34b4179 to
7115f7e
Compare
|
@ljharb Rebased and split into separate commits with benchmarks in each. After testing each optimization in isolation I ended up dropping two of them:
|
|
FWIW, I maintain a Dart port that stays very close to Node I would not treat the Dart benchmark numbers as portable to V8, but the regression set was useful. The fast path had to prove behavior for mixed flat/structured keys ( |
Summary
~1.9x faster
qs.parsevia fast-paths for common cases and manual scanning to replace split/regex in hot loops. No behavior changes, no new deps. All 893 tests pass.Benchmarks
Weighted throughput across 5 representative query string shapes, 3 fresh node processes (Node 23, macOS):
a=1&b=2&c=3&d=4&e=5)user[name]=alice&...)ids[]=1&ids[]=2&...)q=hello%20world&...)Bench script in
bench/workload.jsfor reproduction.What changed
[, skip bracket-parsing entirely.indexOf('%')+indexOf('+')up front — if neither present, return input unchanged.&), in-place scan instead ofsplit().compact()only needed when bracket parsing created sparse arrays.indexOfinsplitKeyIntoSegments.Correctness
All 893 tape tests pass. Equivalence also verified on 25 additional adversarial inputs (empty strings, bare keys, duplicates, deep nesting, percent-encoded specials,
+as space, mixed bracket styles).Happy to split into separate commits per optimization if that helps review.