Files
Michał Pierzchała 423960fe92 docs(1961): record the enableCompileCache() CLI startup measurement — not shipped
Measured module.enableCompileCache() on bin/agent-device.mjs against the issue's
>=50ms warm-run bar, and did not ship it. Harness and raw per-sample data are
retained so every interval can be recomputed:

  node scripts/perf/compile-cache-ab.mjs stats \
    --in docs/cli-compile-cache-startup-samples.json

Metric is elapsed wall-clock. Design: both arms in one interleaved loop, arm
order flipped each iteration (this removes order bias; it does not prove
contention was absorbed, so load is recorded per route), reported as median plus
a bootstrap 95% CI on the median difference with a fixed seed.

Warm (n=120/arm): --version -0.1ms [-0.5,+0.5]; --help -3.6ms [-4.3,-2.9];
open CLI-side path -5.1ms [-5.6,-4.5]. End-to-end `ad open` against a dedicated
throwaway simulator (n=150/arm): -6.4ms [-10.0,-3.8], which agrees with the
CLI-side figure as it should if only CLI startup is affected.

So the warm effect is small but real, and roughly ten times short of the bar. An
earlier revision reported these routes as indistinguishable from zero; that was
an artifact of a busier host, and is corrected here.

Cold cache is a regression: --help +11.3ms [+10.3,+12.4], open CLI-side path
+16.4ms [+15.9,+18.0] — the cost of writing 664-848kB of cache entries.

Records that enableCompileCache() landed in Node v22.8.0 and is Stability 1.1
Active Development at the repo's >=22.12 floor.

Only the warm OS-page-cache leg was measured; `sudo purge` is unavailable
non-interactively here, so the cold-page-cache leg the issue also asked for is
untested and no claim is made about which way it would move. That leg is why
this is Part of, not Closes.

Per the issue's own "measure first, ship only if it's a real win" instruction,
the code change is reverted and only the measurement is retained.

Part of #1961
2026-08-22 19:37:28 +02:00
..