Overview - Router

routerWorkspace

CI Pipeline Executions
- Filtered
Runs
Demo

Insights

Compare tasks
Analytics

Overview

router

Loading workspace stats

Loading workspace insights...

Statistics interval

7 days30 days

Latest CI Pipeline Executions

Filter

Fuzzy

Sort by

© 2026 - Nx Cloud

Terms of Service Privacy Policy Changelog Status Docs Contact Nx Cloud Pricing Company @NxDevTools

routerWorkspace

Average execution time

10m 40s

343 CI pipeline executions

Computation time saved

16d 19h

Cache hit rate

27%

Time to Green

26m 16s

Was 1h 28m, improved by 70%

Succeeded
schiller-manuel-search-middleware-compile-memory
1ddd64e5 perf(router-core): keep search middleware collection optimized CodSpeed's memory instrument flagged the interrupted-navigations client benchmark on the location-reuse changes (react +14.6%, vue +29.8%, solid +10.8% peak memory). Under its worker flags (`--no-opt --predictable`, single threaded) that benchmark's peak is set by a synchronous Maglev compile that happens inside the measured run. `getSearchMiddlewares` is compiled during the preparation calls and then deoptimized on the first property load off a route's options. Before, its only caller was the small `applySearchMiddleware`, which Maglev compiled next and inlined it into, so the callee never tiered up again. Since `build` calls it directly and does not inline it, it became hot again during the measured run, and its recompilation (about four 32 KB zone segments) set the peak. Iterating `destRoutes` with a counted loop instead of `for...of` keeps the function optimized once compiled: no deoptimization and no recompilation in the measured window. Middleware order and live route-option reads are unchanged. Hoisting the option reads alone did not help. Local reproduction with a malloc interposer, CodSpeed's worker flags and seven preparation calls, macOS arm64 / Node 24.8.0 (deterministic peaks): - react: 248880 (base) -> 287760 (+15.6%) -> 248944 with this change - vue: 256704 -> 292656 (+14.0%) -> 256640 - solid: 287408 -> 288240 (+0.3%) -> 287632 These are local native allocations, not a new Linux CodSpeed CI run. Bundle (react-router.minimal gzip): +8. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
by Manuel Sch...
Succeeded
8385
6aec14d8 perf(router-core): keep search middleware collection optimized CodSpeed's memory instrument flagged the interrupted-navigations client benchmark on the location-reuse changes (react +14.6%, vue +29.8%, solid +10.8% peak memory). Under its worker flags (`--no-opt --predictable`, single threaded) that benchmark's peak is set by a synchronous Maglev compile that happens inside the measured run. `getSearchMiddlewares` is compiled during the preparation calls and then deoptimized on the first property load off a route's options. Before, its only caller was the small `applySearchMiddleware`, which Maglev compiled next and inlined it into, so the callee never tiered up again. Since `build` calls it directly and does not inline it, it became hot again during the measured run, and its recompilation (about four 32 KB zone segments) set the peak. Iterating `destRoutes` with a counted loop instead of `for...of` keeps the function optimized once compiled: no deoptimization and no recompilation in the measured window. Middleware order and live route-option reads are unchanged. Hoisting the option reads alone did not help. Local reproduction with a malloc interposer, CodSpeed's worker flags and seven preparation calls, macOS arm64 / Node 24.8.0 (deterministic peaks): - react: 248880 (base) -> 287760 (+15.6%) -> 248944 with this change - vue: 256704 -> 292656 (+14.0%) -> 256640 - solid: 287408 -> 288240 (+0.3%) -> 287632 These are local native allocations, not a new Linux CodSpeed CI run. Bundle (react-router.minimal gzip): +8. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
by Manuel Sch...
M