[dinwwwh]

Requested by dinwwwh · project thread

What

A prefix matcher compares a literal-only prefix, such as oRPC's /api/v1/planets lazy-router prefixes, with one startsWith. Its closure also held the segment-by-segment walk used for prefixes with params and for paths with %. V8 compiles a function whole on its first call, so every app with literal lazy-router prefixes compiled the walk on its first request, though it never ran.

The walk now lives in matchesHead(head, pathname), and the closure calls it only when the literal comparison doesn't apply. Results are unchanged: an old-vs-new diff over 2M random prefixes and paths found 0 differences, and fuzz-wide's prefix model check found 0 too.

Measurements

Node 22, callgrind --single-threaded --hash-seed=1, instructions, main = b57a56d:

	main	this PR
create 5 literal matchers (cold)	623k	575k (-7.7%)
first call of those 5	198k	96k (-51.6%)
create 5 param matchers (cold)	768k	720k (-6.2%)
first call of those 5	493k	504k (+2.2%)
steady, per request: 1 / 10 literal prefixes	1055 / 10034	1055 / 10035
steady, per request: 1 / 10 param prefixes	2167 / 16948	2174 / 16967 (+0.1..0.3%)
rpc / rest cold+3 router share (no prefix matchers)	5.404M / 14.369M	5.422M / 14.379M (+0.33% / +0.06%)

The rpc/rest cold cost is the import pre-parsing one more function (about 18k instructions). Apps with literal lazy-router prefixes save about 150k on their cold start.

Size (esbuild --minify, gzip -9n): 5001 → 5012 B min, 2099 → 2098 B gzip.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[pullfrog]

✅ No new issues found.

Reviewed changes — the segment walk inside createPrefixMatcher's returned closure was extracted verbatim into a module-level matchesHead(head, pathname), called only when the literal startsWith fast path does not apply.

• matchesHead extraction — the loop that walks head segment-by-segment (for params and %-containing paths) is byte-identical to the inline loop it replaces; the closure now falls through to return matchesHead(head, pathname) after the unchanged literal !== undefined && !pathname.includes('%') guard, with the same head/literal captures.
• Rationale documented — the JSDoc explains the hoist keeps the walk out of the closure so a cold start compiles it only when a param prefix or % path needs it.
• Coverage — prefix.test.ts exercises both paths (literal fast path, params, %, catch-all) plus a non-vacuous property check; the router suite passes 73/73 locally.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[codspeed]

Merging this PR will degrade performance by 12.88%

2 warnings

⚠️ 1 benchmark is dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

⚠️ 1 benchmark with a significant change ran on different hardware

Its base and head results were measured on machines with a different CPU, core count or memory, so the change might not come from the code. Run base and head on the same runner type.

Learn more about Macro Runners

See affected benchmarks

❌ 1 regressed benchmark
✅ 28 untouched benchmarks
⏩ 2 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	rou3	64.6 µs	74.1 µs	-12.88%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing claude/project-thread-3j3vmz (a93efd3) with main (3bae110)}

Footnotes

1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[dinwwwh]

CodSpeed Performance Analysis: the one regression comes from when V8 compiles the bench, not from this PR's code.

The flagged benchmark is prefix match, 10 pending lazy routers::rou3, at 64.6 µs → 74.1 µs. That bench only calls rou3's RegExp.test, and this diff doesn't touch rou3 or the bench file. The result came back the same on one re-run.

I replayed CodSpeed's simulation run locally. It runs the real vitest bench for router.bench.ts under callgrind, with CODSPEED_ENV=1 CODSPEED_RUNNER_MODE=simulation and the plugin's V8 flags (--no-opt and the rest), and records one dump per measured call. Instruction counts for the measured call:

bench	base (b57a56d)	head (a93efd3)
prefix, @openapi-spec/router	196,828	177,008 (-10%)
prefix, rou3	90,331	110,791 (+23%)
RPC match, ours	64,724	63,131
REST match, ours	150,800	150,702

The function profiles of the rou3 call show where the difference comes from:

• Base: the bench closure runs as Sparkplug baseline code (LoadICBaseline, Call_..._Baseline_Compact).
• Head: the same closure is still in the Ignition interpreter (GetNamedPropertyHandler, JumpLoopHandler, CallProperty1Handler).

The new matchesHead function changes how much bytecode the earlier benches queue up for Sparkplug. That moves the batch that compiles rou3's bench closure from before its single measured call to after it. CodSpeed runs 7 warm-up calls and then measures one, so the rou3 bench is charged for one interpreted run.

This is the same Sparkplug timing effect described on #198. Nothing in this PR needs fixing for it. Our own prefix bench gets 10% fewer instructions.

---

Generated by Claude Code