Version
0.10.5 (regression against 0.9.0)
Platform
macOS arm64; shipped release binaries of both versions
Summary
Every CLI invocation pays a fixed startup cost that 0.9.0 did not. On a small corpus (php, 2,807 files) where 0.9.0 completes in 1.4 s, 0.10.5 takes ~7.9 s — and 4.9 s even with a warm daemon, so roughly 3.5 s is not recoverable by the documented mitigation.
Measurement
Same corpus, same host, --mode full --persistence true.
|
wall |
| v0.9.0 |
1.4 s |
| v0.10.5, no daemon running |
8.0 s / 7.9 s / 7.9 s |
v0.10.5, after daemon start |
4.9 s / 4.9 s |
The three no-daemon runs used the same HOME and CBM_CACHE_DIR consecutively, so this is not a cold-cache artifact — the daemon does not persist between CLI invocations on its own, and each command re-pays the bootstrap. That is what the emitted hint is pointing at:
hint: this command started a temporary CBM daemon. `codebase-memory-mcp daemon start` keeps one
warm and removes this startup cost from every CLI command.
But "removes" overstates it: daemon start takes 7.9 s → 4.9 s, still 3.5 s above 0.9.0.
Why it matters
The absolute number is small, but it is paid per invocation, so it dominates exactly the workflows that call the CLI repeatedly:
- hook-driven usage (
hook_augment, PostToolUse hooks) fires per tool call
- scripts and CI steps that invoke several commands in sequence
- any small-repo or incremental use, where 3.5–6.5 s of fixed cost exceeds the actual work
It also distorts benchmarking: on small corpora the fixed cost is most of the wall time (perl: 0.6 s → 6.9 s is almost entirely this, not throughput).
Reproduction
W=$(mktemp -d)
for i in 1 2 3; do
time env HOME="$W" CBM_CACHE_DIR="$W/.cache" ./codebase-memory-mcp cli index_repository \
--repo-path /path/to/small-repo --mode full --name "run$i" --persistence true
doneQuestions for triage
- How much of the 3.5 s warm floor is the version-cohort lease / rendezvous handshake, and can it be skipped when the daemon is already known-compatible?
- Should a CLI invocation start a temporary daemon at all when it is going to retire it moments later, or should the one-shot path bypass daemon coordination entirely?
- If the daemon is the intended steady state, should
daemon start be part of install rather than a hint printed after the cost has already been paid?
Context: found while A/B-benching 0.9.0 vs 0.10.5 across 11 corpora for #1654. Separate from #1654 (Linux memory) and #1669 (cross-LSP throughput) — this one is platform-independent and affects every invocation.
Version
0.10.5 (regression against 0.9.0)
Platform
macOS arm64; shipped release binaries of both versions
Summary
Every CLI invocation pays a fixed startup cost that 0.9.0 did not. On a small corpus (php, 2,807 files) where 0.9.0 completes in 1.4 s, 0.10.5 takes ~7.9 s — and 4.9 s even with a warm daemon, so roughly 3.5 s is not recoverable by the documented mitigation.
Measurement
Same corpus, same host,
--mode full --persistence true.daemon startThe three no-daemon runs used the same
HOMEandCBM_CACHE_DIRconsecutively, so this is not a cold-cache artifact — the daemon does not persist between CLI invocations on its own, and each command re-pays the bootstrap. That is what the emitted hint is pointing at:But "removes" overstates it:
daemon starttakes 7.9 s → 4.9 s, still 3.5 s above 0.9.0.Why it matters
The absolute number is small, but it is paid per invocation, so it dominates exactly the workflows that call the CLI repeatedly:
hook_augment, PostToolUse hooks) fires per tool callIt also distorts benchmarking: on small corpora the fixed cost is most of the wall time (perl: 0.6 s → 6.9 s is almost entirely this, not throughput).
Reproduction
Questions for triage
daemon startbe part of install rather than a hint printed after the cost has already been paid?Context: found while A/B-benching 0.9.0 vs 0.10.5 across 11 corpora for #1654. Separate from #1654 (Linux memory) and #1669 (cross-LSP throughput) — this one is platform-independent and affects every invocation.