Benchmarks
Honest numbers. Reproducible. Updated quarterly. Numbers marked "coming soon" have not been measured against the reference hardware yet — we will not publish guesses.
Indexing
Wall-clock time from canopy index . invocation to "index complete" on a cold cache.
Includes tree-sitter AST parsing, Tantivy search index build, and SQLite write.
Reproduction
git clone <repo> /tmp/bench-repo
cd /tmp/bench-repo
rm -rf ~/.canopy/indexes/bench-repo # clear cached index
time canopy index . --with-search| Repository | Files | Time | Index size | Status |
|---|---|---|---|---|
| ironpine-labs/platform (Pith monorepo) Internal reference — TypeScript/React Native monorepo | 622 | 2.6s (AST + search) | ~11 MB | validated |
| torvalds/linux (v6.6) Linux kernel — ~76K C source files | ~76,000 | coming soon | coming soon | coming soon |
| facebook/react (main) React source — TypeScript monorepo | ~6,800 | coming soon | coming soon | coming soon |
| microsoft/TypeScript (main) TypeScript compiler — TypeScript on TypeScript | ~3,200 | coming soon | coming soon | coming soon |
ironpine-labs/platform (Pith monorepo): Validated 2026-04-15 on build host. 98.4% parse success rate (10 config files excluded by JS grammar version mismatch).
Search latency
Measured end-to-end from tool call dispatch to result return within a running
canopy serve process.
Does not include MCP transport overhead or LLM inference time.
Reproduction (keyword)
canopy index /tmp/bench-repo --with-search
# then in your MCP client:
# call canopy_search with the query and repo params
# check canopy stats --json for latency percentiles| Query type | p50 | p95 | p99 | Status |
|---|---|---|---|---|
| Keyword search | 29 ms | — | — | validated |
| Semantic (vector) search | — | — | — | coming soon |
| Hybrid (keyword + semantic) | — | — | — | coming soon |
Keyword p50 of 29 ms includes cold process start (Rust binary init + SQLite open + Tantivy load).
In a persistent canopy serve process, hot-path query time is sub-millisecond.
MCP tool call latency
End-to-end latency for composite workflow tools. These tools perform multiple internal operations (graph traversal, health checks, git history) so latency is higher than raw search — but each call replaces work the agent would otherwise do in 3-8 separate steps.
| Tool | What it does | p50 | p95 | Status |
|---|---|---|---|---|
| canopy_prepare | Pre-modification impact analysis: dependents, health, coverage, blame | 350 ms | — | validated |
| canopy_validate | Post-modification verification: import resolution, breaking changes | — | — | coming soon |
| canopy_understand | Code comprehension: API surface, responsibility summary, usage patterns | — | — | coming soon |
| canopy_health_check | Full repository health scan: 21+ detectors | 255 ms | — | validated |
| canopy_search | Full-text keyword search across indexed files | 29 ms | — | validated |
Contribute a benchmark
Have Canopy running on a large or interesting codebase? We would love to include your numbers here. Send results to [email protected] with:
- Repo name and approximate file count (you can anonymize the repo name)
- Hardware spec (processor, RAM)
-
Output of
time canopy index . --with-search -
Canopy version (
canopy --version)
We include all submitted benchmarks that are reproducible, regardless of whether they reflect well or poorly on Canopy. Honest data builds trust.
Run these benchmarks yourself on your own codebase.
Start 14-Day Free Trial