mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-10-22 06:09:35 +08:00
Martin Vogel
63fb7b3db5
81264814built the production allocator as mimalloc's release build (-DMI_DEBUG=0). That bought a large speed-up, but it raised what macOS charges an index worker, its phys_footprint: | peak phys_footprint | v0.11.0 | main | |---|---:|---:| | TypeScript | 1.25 GB | 1.94 GB | | dotnet/runtime | 4.5 GB | 12.7 GB | The 2026-10-09 bench missed most of this, because it sampled RSS. The difference is one compile-time branch in mimalloc's unix decommit. With MI_DEBUG or MI_SECURE>2, a purged range is mprotect(PROT_NONE)'d and flagged needs_recommit. A release build leaves it "committed". When the arena hands such a range out again, it is re-accounted as a whole with MADV_FREE_REUSE (arena.c, _mi_os_reuse). macOS then charges every page of it to the footprint, touched or not. On macOS, take the recommit path in every build. Linux and Windows keep upstream's behaviour; there MADV_DONTNEED already drops RSS at once. Measured on Apple arm64 (macOS 26.6), mainec4fbd3avs this change, cold full indexes interleaved with main (C#: 2 runs each, in the same session as main): | corpus | footprint before | footprint after | change | wall time | |---|---:|---:|---:|---| | TypeScript | 1.98 GB | 1.09 GB | -45 % | unchanged | | kubernetes | 2.92 GB | 1.88 GB | -35 % | unchanged | | dotnet/runtime | 12.6 GB | 4.9 GB | -61 % | unchanged | | linux kernel | 16.0 GB | 13.5 GB | -16 % | 574 -> 559 s | The graph is byte-identical: TypeScript, kubernetes and django give the same nodes, edges and CALLS-set hash. dotnet/runtime is now close to v0.11.0's 4.5 GB. Measured but not taken: - the whole debug build, which costs ~5 % wall time on C#; - MI_STAT=2, MI_PADDING=1 or MI_ENCODE_FREELIST=1 alone, none of which moves the footprint; - MIMALLOC_PURGE_DELAY=0, which is already set. Vendored file changed in place (precedent1f674c80); its hash in scripts/vendored-checksums.txt is updated and security-vendored.sh passes. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>