Documentation
¶
Overview ¶
indexing_throughput measures the wall time, peak memory, and per-phase breakdown of code-graph's pipeline.Run() against a target directory.
Plan 4 T3b (~/Documents/knowledge-base/plans/2026-05-06-codegraph-followup.md post-roundtable). Closes performance gaps #8 (memory footprint), #9 (cold- start), and #10 (indexing throughput) from the 2026-05-06 roundtable META_SYNTHESIS F5.
MEASUREMENT APPROACH:
The harness drives Pipeline.Run() in-process (not via the MCP binary) because:
- The dominant work — tree-sitter parsing, multi-pass extraction, SQLite writes — is exercised identically.
- In-process measurement is reproducible (no subprocess setup).
- We can wire Pipeline.Progress callbacks to record per-phase wall times, which the binary doesn't surface.
Memory measurement uses runtime.MemStats. This captures Go-side heap allocations but NOT CGO-side (tree-sitter) memory. The Sys field reflects total OS memory committed by the Go runtime including CGO arena overhead, so we report both HeapInuse and Sys peak.
Cold-start time is measured separately: time from process start to the first phase callback ("discover").
Output is a JSON baseline file with the same schema pattern as bench/research/baselines/2026-05-06-mcp-latency.json (Plan 3 Phase B).
Usage:
go run ./bench/research/indexing_throughput \
-target . \
-output bench/research/baselines/2026-05-06-indexing-throughput.json
# Incremental run (re-index against an already-indexed project):
go run ./bench/research/indexing_throughput -target . -mode incremental
Source Files