Repository navigation
perf(router): measure LP1 + LP4 lazy-include costs; record both as deferred - #546
Merged
Merged
Conversation
…ferred No behavior change. Completes the lazy-include perf audit: LP1 and LP4 were the last two items still labelled "deferred (needs-design)" — implying planned work. Measuring them (same as LP3) shows they are not worth optimizing either. Measured (lazy-include-cost.bench.ts, `vitest bench lazy-include-cost`): - LP1 (include with M routes runs its handler once per route, pruned-per-routeKey cache): warming all 30 routes of a 30-route include from cold is ~20x the cost of re-hitting them (cache hits) — ~20-25us/route, paid once per route per isolate, amortized to 0. Worst case (every route hit); most includes are small. - LP4 (cold document request resolves twice, isSSR=false classify + isSSR=true render, both miss the isSSR-keyed cache): the double resolve is ~1.9x a single — ~20-25us waste per cold document request, once per route per isolate, amortized to 0. Both are the same flavor as LP3: cold-start, tens of microseconds, amortized to ~0. The fixes are architecturally risky (LP1 = unpruned cache + prune-on-read; LP4 = split isSSR-dependent state out of the cached tree, touching shortCodes + the semantic matrix). Risk >> reward -> deferred as documented decisions. Changes: - lazy-include-cost.bench.ts: add LP1 (warm-all-from-cold vs re-hit) and LP4 (double vs single resolve) benches + a makeMultiRouteInclude helper; render() takes isSSR. Header documents all three (LP1/LP3/LP4). - lazy-include-perf.test.ts: rewrite the LP1 and LP4 it.todos as MEASURED/deferred with the numbers. - docs/internal/matching-stability-review.md: LP1 and LP4 sections rewritten as MEASURED, DEFERRED (not worth it) with numbers; Follow-up notes all three are now quantified and no optimization is warranted.
commit: |
3 tasks done
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.
What & why
No behavior change. Completes the lazy-include performance audit. LP1 and LP4 were the last two items still labelled "deferred (needs-design)" — which implies planned optimization work. Measuring them (the same treatment LP3 just got in #545) shows neither is worth optimizing, so this records them as measured/deferred with numbers and a reproducible benchmark.
The numbers (
vitest bench lazy-include-cost)LP1 — an include with M routes runs its handler once per route (the cache is pruned per
routeKey):LP4 — a cold document request resolves twice (
isSSR=falseclassify +isSSR=truerender), both miss theisSSR-keyed cache:Verdict (all three now measured)
All three are cold-start, tens-of-microseconds, paid once, amortized to zero. The fixes are architecturally risky — LP1 needs an unpruned-cache + prune-on-read (a naive handler-identity key thrashes, verified); LP4 (and LP3) need
isSSR-dependent state split out of the cached tree, touching shortCodes + the semantic matrix. Risk ≫ reward → deferred as documented decisions. No optimization is warranted.Changes
lazy-include-cost.bench.ts— add LP1 (warm-all-from-cold vs re-hit) and LP4 (double vs single resolve) benches + amakeMultiRouteIncludehelper;render()takesisSSR. Header now documents LP1/LP3/LP4.lazy-include-perf.test.ts— rewrite the LP1 and LP4it.todos as MEASURED / deferred with the numbers.docs/internal/matching-stability-review.md— LP1 and LP4 sections rewritten as MEASURED, DEFERRED (not worth it); Follow-up notes all three are quantified and no optimization is warranted.Test plan
isSSR)vitest bench lazy-include-costruns and produces the tables aboveNotes
Follow-up to #545 (LP3). LP1/LP3/LP4 are now all measured-and-documented; the lazy-include perf audit is complete with no code optimization needed.