出處聲明：以下數字為上游官方 benchmark（Apple M3 Pro、docs/BENCHMARK.md），本站未在同等硬體重測——列出來是讓你知道這工具「能多快」，不是本站實測。
索引速度
| 專案 | 耗時 | 規模 |
|---|
| Linux kernel（full index） | 3 分鐘 | 28M LOC、75K 檔 → 4.81M 節點 / 7.72M 邊 |
| Linux kernel（fast index） | 1m 12s | 1.88M 節點 |
| Django | ~6 秒 | 49K 節點 / 196K 邊 |
查詢延遲
| 操作 | 時間 | 說明 |
|---|
| Cypher query | <1ms | relationship traversal |
| 名稱搜尋（regex） | <10ms | SQL LIKE 預過濾 |
| 死碼偵測 | ~150ms | 全圖掃描 + degree 過濾 |
| Trace 呼叫路徑（depth=5） | <10ms | BFS 遍歷 |
為什麼快
- RAM-first pipeline：所有索引在記憶體跑（LZ4 HC 壓縮讀入、in-memory SQLite、結束才單次 dump）。
- 平行 worker：
pass_parallel.c 的 worker pool 用滿 CPU。
- 記憶體用完即釋放：索引完回歸 OS，不常駐。
- 增量更新：之後只處理變更，不是每次全跑。
Token 效率
官方 benchmark：5 個結構查詢約 3,400 token，而逐檔 grep 探索同一批問題約需 412,000 token——減少 99.2%。
file-by-file grep: ~412,000 tokens
codebase-memory-mcp: ~3,400 tokens
省下: 99.2%
圖查詢取代幾十次 grep/read 循環：agent 不用把整個檔案塞進 context 才能找到答案。
可設定的資源參數
| 變數 | 說明 |
|---|
CBM_WORKERS | 覆寫平行索引 worker 數（容器內 cgroup 配額誤判時用） |
CBM_MEM_BUDGET_MB | 顯式設定記憶體預算上限 |
看完這頁你應該能說出：CBM 能在 3 分鐘內索引 kernel 的關鍵（RAM-first + 平行 + 增量）、Cypher <1ms 與 trace <10ms 的數量級、以及「圖查詢取代 grep」為何省下 99.2% token。