docs(plans): record uptime-matched wonder working-set re-read — 4.5x/2.0x reduction confirmed flat

This commit is contained in:
Joseph Doherty
2026-08-12 18:25:00 -04:00
parent 4a026d256e
commit d6b1942932
@@ -588,6 +588,7 @@ Measured as a fixed-compile-count A/B (both nodes compile an identical startup s
| Site metadata triple / `NativeHeapMemoryBlock` | 6,640 / 6,593 | **800 / 753** (8.3× / 8.8× down) |
| Central metadata triple / `NativeHeapMemoryBlock` | 2,699 / 2,681 | **849 / 831** (3.2× down) |
| Site / Central working set | 2,814 / 1,374 MB | 612 / 663 MB (post-fix read at ~5 min uptime — not uptime-matched; the metadata counts are the controlled result) |
| Site / Central working set — **uptime-matched re-read** (26.3 min, same `20f2ae05` boot) | 2,814 / 1,374 MB (24+ min) | **620 / 695 MB** — flat vs the 5-min read (+8 / +32 MB), so the comparison is now clean: **4.5× / 2.0× working-set reduction** |
`CachingScriptMetadataResolver` shows exactly 1 instance per process in the gcdump — active in production. Calibration note: the steady-state residual is a **fixed** cost of roughly one shared closure set + statics (~800 for 21 scripts ≈ 38/script amortized), not the per-compile ≤~10 growth figure — the growth figure applies to *additional* compiles (rig-verified at +2/compile), the fixed cost to the startup set. Follow-up lead (not closed by this): re-test the complex `AddTemplateScript` OOM on wonder — that path was shown twice not to compile scripts, but the OOM signature (large allocation failing with GBs free) matches the native-heap state this leak produced, and the test is now cheap.