Skip to content

perf: cut query-string parsing cost on the request hot path#53

Merged
jkyberneees merged 1 commit into
masterfrom
perf/queryparams-hot-path
May 31, 2026
Merged

perf: cut query-string parsing cost on the request hot path#53
jkyberneees merged 1 commit into
masterfrom
perf/queryparams-hot-path

Conversation

@jkyberneees
Copy link
Copy Markdown
Collaborator

Summary

lib/utils/queryparams.js runs on every request (and again per nested-router level), so it's squarely on the hot path. Two pieces of per-request work were avoidable, and removing them speeds up query parsing ~36% with no behavior change and no API change.

1. Unconditional array-notation regex

new URLSearchParams(search.replace(/\[\]=/g, '=')) scanned/allocated a regex replacement over every query string, even when no a[]= array notation existed. Now gated on a cheap search.indexOf('[]=') check.

2. Per-parameter allocation for the prototype-pollution guard

name.split(/[.[\]]+/).filter(Boolean) allocated a throwaway array for every parameter on every request, solely to check for __proto__ / prototype / constructor segments. Those are vanishingly rare in real traffic. The split now runs only when the name contains proto or constructor (a substring superset of all three dangerous keys), so normal parameters skip the allocation entirely.

Behavior is identical

The dangerous-key filtering and array/repeat grouping are unchanged. Verified by two new tests in tests/router-coverage.test.js:

  • repeated + []= array notation grouping
  • all prototype-pollution key forms (__proto__, prototype, user.constructor, a[__proto__]) are stripped, query object stays null-prototype, and Object.prototype is not polluted.

I also diffed old-vs-new output across 11 URLs (including every dangerous form) — 0 differences.

Measured (Node 22, 3M iterations, warmed)

Input master this PR Δ
?q=node&page=2&limit=20 489 ns/op 312 ns/op −36% / +57% ops/s
?id[]=1&id[]=2&tag=x 595 ns/op 428 ns/op −28%
no query (/api/users) 10.7 ns/op 10.7 ns/op unchanged

Validation

  • Full suite: 71 passing (was 69 + 2 new tests).
  • lib/utils/queryparams.js: 100% line coverage.
  • standard lint clean.

Out of scope (deferred)

A second optimization — nested routers re-parse the (identical) query string at every level — was identified but deliberately deferred: it requires adding per-request state and a correctness decision about query immutability across the middleware chain. Happy to follow up in a separate PR if wanted.

🤖 Generated with Claude Code

queryparams runs on every request. Two pieces of per-request work were
avoidable:

1. `search.replace(/\[\]=/g, '=')` ran a regex over every query string even
   when no `a[]=` array notation was present. Now gated on `indexOf('[]=')`.

2. `name.split(/[.[\]]+/).filter(Boolean)` allocated an array per parameter,
   every request, solely to guard against `__proto__`/`prototype`/`constructor`
   keys. The split now runs only for names containing `proto`/`constructor`
   (a superset of all dangerous keys), so normal params skip it entirely.

Behavior is identical — verified across repeated/array params and all
prototype-pollution key forms (new tests in router-coverage).

Measured (Node 22, 3M iters):
  typical  ?q=node&page=2&limit=20 : 489 -> 312 ns/op  (-36%)
  array    ?id[]=1&id[]=2&tag=x    : 595 -> 428 ns/op  (-28%)
  no-query /api/users             : 10.7 ns/op (unchanged)

Suite: 71 passing, queryparams.js at 100% line coverage.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@jkyberneees jkyberneees merged commit 3e0d4ff into master May 31, 2026
5 checks passed
jkyberneees added a commit that referenced this pull request May 31, 2026
- Bump package.json 5.0.0 -> 5.0.1 for the patch release (fixes from #52,
  perf from #53).
- Remove the TRON wallet address from the README Support section; PayPal
  link retained.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant