Performance and latency

Fuse builds the persistent index once and reads it warm across calls. This page publishes measured latencies as a regression fence: every number is traceable to a recorded result file under tests/benchmarks/results, regenerated with fuse eval performance, fuse resident-latency, and fuse testexec. Timings are environment-dependent; read them as within-environment SLOs, not cross-machine guarantees.

Warm persistent index

Fuse analyzes each source file and stores the result in a persistent SQLite database at .fuse/fuse.db (WAL mode). The MCP server (fuse mcp serve) and the host process reuse that store, so scoped calls do not re-parse unchanged files. Single-file incremental re-index clears and re-extracts only the changed file's syntax rows; it does not recompute cross-file semantic edges, which a full re-index refreshes.

One-shot CLI commands pay startup cost on every invocation. A long-running server pays it once per session; warm latencies below apply after that first pass. The separate live compilation workspace is opt-in with FUSE_RESIDENT=1. Cache key derivation and store layout are in Caching Internals.

Warm read verbs (two scales)

Each verb is the primitive the matching MCP tool calls, timed over 25 iterations at two scales: NodaTime (512 files, 7,657 symbols, performance.json) and eShopOnWeb (287 files, 1,216 symbols, performance-eshop.json).

Every recorded warm read sits inside a sub-second budget on this machine. eShopOnWeb is faster in this run, but two repositories do not establish a proportional scaling law. fuse_impact reads ~0 ms on these syntax-mode checkouts because there is no semantic graph to walk; on a semantically loaded checkout the query walks real edges, bounded by neighborhood size.

Verify verbs (NodaTime, resident-latency.json)

fuse_check answers from a live resident workspace when one serves the root. This path is opt-in with FUSE_RESIDENT=1; the default store-backed path is not represented by these timings. The operations below were timed over 25 iterations against held compilations:

The analyzer timing measures raw analyzer execution against the held compilation. It does not measure editorconfig severity mapping or establish full CI parity. The resident workspace warms once (build plus rehydrate) at about 14.1 seconds and holds the compilations at 162 MB RSS for the NodaTime checkout.

Test execution (testexec.json)

The build-grade covering-test runner (behind fuse_test) runs the selected covering subset through the real dotnet test:

The first run pays the full build; each subsequent incremental run (one file changed) is about 1.8 s. The sub-second emit fast-path (run the covering subset in-process against the emitted assembly, no build) is a named follow-up.

Cold start

Measured on NodaTime (performance.json) and eShopOnWeb (performance-eshop.json):

fuse mcp serve uses syntax-first cold start by default, then upgrades the semantic graph in the background. Set FUSE_BG_UPGRADE=0, false, no, or off to make the first read index synchronously. The explicit fuse index command is always synchronous.

Distribution

Fuse distributes as a framework-dependent .NET global tool and as self-contained runtime-specific packages:

Roslyn structural analysis is always included; there is no trimmed or regex-only binary.

How these are regenerated

fuse eval performance --repo NodaTime     # warm reads + cold start -> performance.json
fuse eval performance --repo eShopOnWeb    # second scale point -> performance-eshop.json
fuse testexec                              # build-grade test execution -> testexec.json
fuse resident-latency                      # verify verbs -> resident-latency.json

Token efficiency (median tokens a review returns) is on Benchmarks. Test-selection latency is the covering-tests query inside fuse_impact; a standalone timer for it is follow-up work.

Next

Read Benchmarks for recall and token suites, Caching Internals for store reuse, or Pipeline for the stages behind a fusion.