I indexed a 96k-file Linux kernel tree in 2m51s on a laptop — benchmarking two code-graph MCP servers

y.senthilvasan — Sat, 24 Oct 2026 19:36:33 +0000

I indexed a 96k-file Linux kernel tree in 2m51s on a laptop — benchmarking two code-graph MCP servers

Disclosure up front: I'm the author of SMP (Structural Memory Protocol) — an open-source (MIT) MCP server that keeps a live structural code graph. This post is the full methodology and numbers; everything below is reproducible.

Why a code graph, not more grep

Coding agents can read files. What they mostly can't do is answer structural questions: who calls this, what breaks if I change it, which tests cover it. Grep gives you matches, not a map. Embedding-based RAG finds "similar" code, rarely "connected" code. So SMP maintains a graph: tree-sitter parses each file into nodes (functions, classes, modules) and edges (calls, contains, imports), stored in a single memory-mapped file with a journaled write-ahead log — no Postgres, no Neo4j, no embeddings.

The machine, and why it matters

Every number below was measured on the same laptop: an 8-thread 11th-gen Intel i7-1165G7, 14 GB RAM, NVMe, Linux, no GPU. Both tools did a fresh full index of the identical directory tree. No vendor numbers are mixed in.

Headline: the Linux kernel

Corpus	SMP	codebase-memory-mcp (fast mode)
Linux kernel snapshot — 95,937 files (72,171 parsed)	2 min 51 s — 839,516 nodes, 4,066,943 edges, 2.2 GB graph, 6.5 GB peak RAM	13 min 14 s — 4.8 GB index

4.6× faster on the same hardware, same tree. One caveat: codebase-memory-mcp excluded 36 directories by design (gitignored/vendor paths), so node counts describe different graph models — wall-clock on the same input is the comparison.

Small repo

Corpus	SMP	codebase-memory-mcp
208-file Python repo	0.99 s — 4,575 nodes / 18,862 edges	5.27 s — 4,346 nodes / 22,002 edges

What a store can actually do

Micro-benchmark (benchmarks/benchmark_scale.py --nodes 60000 --depth 3), synthetic graph, no MCP overhead:

60,000 node upserts: 207 ms
240,000 edge upserts: 916 ms
Point lookup: p50 0.000 ms, p95 0.001 ms
Depth-3 BFS: p50 0.057 ms, p95 0.084 ms

The bug my own benchmark caught

This is my favorite part. locate used to re-load every node and re-tokenize the entire BM25 corpus on every query — 1,493 ms p50 on a 4,575-node graph. On the 839k-node kernel graph it OOM-killed my desktop twice (systemd-oomd took out the whole session).

The fix: a monotonic store revision counter plus an engine-side corpus cache (≤250k nodes; larger graphs fall back to the original path). Results are byte-identical to the pre-fix code, covered by 9 new equivalence/invalidation tests — and locate dropped to 40–85 ms p50 (~15–37× faster).

Other MCP tools on a warm 4,575-node graph: smp_context p50 29.9 ms, smp_file_outline p50 9.3 ms.

Try it

One line wires the MCP server + agent skill into Claude Code, OpenCode, Codex or Cursor:

curl -fsSL https://raw.githubusercontent.com/offx-zinth/SMP/main/install.sh | bash

Repo (MIT, benchmark scripts included so you can re-run every table above on your own hardware): https://github.com/offx-zinth/SMP

What's still open

Incremental re-index on partial edits at >500k nodes; monorepo-scale retrieval without vectors; Apple Silicon timing runs. If you run agents on a large repo, I genuinely want to know where it breaks for you.

DEV Community: y.senthilvasan

I indexed a 96k-file Linux kernel tree in 2m51s on a laptop — benchmarking two code-graph MCP servers

I indexed a 96k-file Linux kernel tree in 2m51s on a laptop — benchmarking two code-graph MCP servers

Why a code graph, not more grep

The machine, and why it matters

Headline: the Linux kernel

Small repo

What a store can actually do

The bug my own benchmark caught

Try it

What's still open