The search was not the slow part. The startup was. In 0.2.53 and 0.2.54, a warm `search` on the same repository could still cost roughly 5.5 seconds because every fresh process reopened a snapshot and rebuilt too much state around it. By 0.2.56, that same path was down to about 80 milliseconds. This is the short story of how codedb removed that startup tax.
TL;DR
On the same `openclaw` corpus, warm `tree` and warm `search` dropped from roughly 5.5 seconds in `0.2.53` / `0.2.54` to roughly 80 milliseconds in `0.2.55 / 0.2.56`. Warm tree RSS dropped from about 3.3GB to 193MB. `0.2.56` did not change the performance profile. It was the hotfix that made sure users actually got it.
Benchmarks
The easiest way to understand this release wave is to look at the warm path first. We reran the shipped darwin-arm64 binaries locally on Apple Silicon against `openclaw`, giving each version its own clean corpus copy and a fresh `HOME`. These are numbers from the binaries users actually download.
Why warm mattered more than cold
Cold indexing still matters. On a first run, it is the whole experience. But agent workflows are dominated by the warm path: reopened snapshots, short-lived CLI invocations, fresh MCP sessions, and secondary project loads. That is where repeated startup work hurts.
You can see that in the cold chart. `0.2.54` improved cold `tree`, and `0.2.55` kept it roughly flat. That is good, but it is not the main story. The main story is that `0.2.55` stopped paying the warm-start bill over and over again.
Release timeline
If you only want the sequence, here is the short version.
v0.2.53
Trigram v2
Indexing got materially lighter with integer doc IDs, batch accumulation, and faster intersections.
36% faster indexing, 63% faster dense queries
v0.2.54
mmap-backed postings
The trigram index moved out of giant heap structures, which improved cold starts and reduced pressure on memory.
cold tree 6.36s → 5.67s
v0.2.55 / 0.2.56
Warm reopen
Persisted state started getting reused directly, and the hotfix on top made install/update actually deliver that version.
warm tree 5.46s → 84ms
v0.2.53
Trigram v2
Indexing got materially lighter with integer doc IDs, batch accumulation, and faster intersections.
36% faster indexing, 63% faster dense queries
v0.2.54
mmap-backed postings
The trigram index moved out of giant heap structures, which improved cold starts and reduced pressure on memory.
cold tree 6.36s → 5.67s
v0.2.55 / 0.2.56
Warm reopen
Persisted state started getting reused directly, and the hotfix on top made install/update actually deliver that version.
warm tree 5.46s → 84ms
What changed for users
The user-facing change is rhythm. `tree` becomes cheap enough to call early. `search` stops feeling like a detour. MCP secondary-project loads stop turning into a RAM event. And because warm reopen is no longer rebuilding the world, codedb starts feeling less like a daemon you have to accommodate and more like a part of the loop itself.
This is also the point where the surrounding features start to matter more. `codedb_query` makes the MCP side more composable, WAL-backed ranking starts using real behavior instead of static heuristics, and `0.2.56` closes the loop by fixing the install/update path. Performance work only matters if users actually end up running the faster binary. The project itself lives on `justrach/codedb` on GitHub.
Install `0.2.56`, not `0.2.55`
`0.2.55` is where the warm-reopen performance jump landed. `0.2.56` is the one people should actually install and share, because it ships the same faster path and fixes the install/update flow so users reliably land on the right binary.
Upgrade
If you are on anything older than `0.2.55`, the warm-path improvement alone is reason enough to move. If you already took `0.2.55`, `0.2.56` is the hotfix that makes install and update line up with the actual GitHub release instead of just pointing at it.
curl -fsSL https://codedb.codegraff.com/install.sh | bash # or if you already have it: codedb update