Files
codebase-memory-mcp/tests
Martin Vogel 3eeefa2d2a perf(sha256): compress blocks on ARMv8 SHA2 / x86 SHA-NI (#2441)
Every process start fingerprints its own executable for the daemon build
identity, and the hook path pays for that before it can answer. With the
portable transform that was ~1.2 s of CPU for the ~300 MB binary, so on a
slower machine hook-augment hit its 2000 ms deadline and printed nothing
(#2441).

Two changes in src/foundation/sha256.c:
- cbm_sha256_update compresses whole blocks straight from the input instead
  of copying every byte through the context buffer.
- Block compression runs on the CPU's SHA-256 instructions when it has them:
  ARMv8 SHA2 (sysctl on macOS, HWCAP on Linux, IsProcessorFeaturePresent on
  Windows) or x86 SHA-NI (CPUID). The backend is probed once; the portable
  transform stays the fallback.

Measured on an Apple arm64 Mac (macOS 26.6), release builds of main 72a2c0bc
and of this change, hook-augment SessionStart in fresh isolated dirs, 9
interleaved runs, medians:
- hook-augment: wall 1.448 s -> 0.376 s, user CPU 1.162 s -> 0.097 s
- SHA-256 of the 303 MB binary: 1.18 s -> 0.095 s CPU per pass (the
  block-direct update alone, portable rounds: 0.74 s)
- with CBM_HOOK_DEADLINE_MS=1000 (a slower machine): before, exit 0 with
  empty stdout after 1.01 s; after, the full 188-byte answer in 0.37 s

Digests are unchanged: the build id the new binary logs equals the file's
SHA-256, and the hook output is byte-identical. A new test compares the
hardware and portable backends at every length 0..299 and at block-boundary
sizes up to 1 MiB under eight update chunkings, plus the NIST million-'a'
vector; it fails if the ARM schedule is broken or if Apple arm64 falls back
to portable. The x86 path was checked under qemu-x86_64 -cpu max (2,436
comparisons equal, million-'a' correct) and falls back to portable on a CPU
without SHA-NI. On a Windows arm64 VM the probe picks the hardware path:
0.094 s against 0.82 s portable for the 303 MB binary, digest equal to
sha256sum's.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
2026-10-09 20:00:44 +02:00
..