Benchmarks
Honest numbers. Reproducible. Updated as the suite expands. Rows marked "coming soon" are explicitly unmeasured against the reference hardware — they are placeholders for runs we haven't completed, never invented numbers.
The full comparison matrix — Canopy versus grep, ripgrep, Sourcegraph OSS, and the other code-intelligence tools in the space — is in progress. We will publish each comparison as its methodology is locked in and the run is reproducible, not before.
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 across the bundled 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 support@canopy.ironpinelabs.com 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