Performance and storage

Supercov separates timings that it can measure safely from overhead that requires an explicit control run. It never runs a user’s command a second time automatically: an arbitrary test command can write data, call paid services, or be intentionally non-repeatable.

Per-run measurements

Every coverage run prints and stores monotonic durations for:

The fields are stored in .supercov/runs/<run-id>/run.json and returned by supercov runs --json. Total duration is stored separately as durationMs.

The non-test phases are not automatically labelled “overhead.” For example, a test script that ordinarily performs its own build may overlap work with the instrumented-build phase. True end-to-end overhead must compare equivalent cold runs or equivalent warm runs of the same command.

Reproducible comparison

Run the command without and with Supercov under the same cache state. Use at least three alternating pairs and report the medians. Never compare a cold VM, browser, package-manager, or build-cache run with a warm one.

/usr/bin/time -p npm test
/usr/bin/time -p npx supercov -- npm test

Package acquisition is a separate user-interface cost. A cold npx download depends on the registry and network; a cached npx resolution should be reported separately from Supercov’s recorded phases.

Reference measurement, not a guarantee

On 2026-08-26, the 30-test the reference application Playwright suite running across seven cycle-restored VMs produced a 43.02 s uncovered control and two valid warm Supercov measurements of 46.30 s and 40.20 s. The slower covered sample is 1.076x the control and therefore remains below the current 1.1x realistic-suite target; the faster result illustrates why multiple alternating pairs are still required for a statistically stable benchmark. The 40.20 s run spent 38.63 s inside the unchanged test command and 1.04 s total on initialization, workspace refresh, adapter restoration and evidence publication. It attributed 6,727 server records across 30 remote launches with zero corrupt evidence records.

VM-image creation is not included in these warm comparisons. A changed engine fingerprint intentionally caused a one-time 119 s rebake before the first post-change run; comparing that cold run with a warm control would be invalid.

On 2026-08-24, the 29-test the reference application offline suite on the development Mac produced this warm pair:

The test-command durations were effectively identical in this pair. The extra instrumented build accounted for about 84% of the measured difference. A seven-sample isolated workspace refresh had a 270 ms median and 447 ms maximum. The built output grew from 2,781,273 to 3,094,366 logical bytes (+11.3%). A cached npx supercov help added a 686 ms median over direct CLI startup; the first observed npx resolution took 2.22 s.

Cold VM-image runs were 170.34 s without Supercov and 175.44 s with Supercov in the same session, but a single cold pair is too noisy for a general percentage. Both spent approximately 124 seconds preparing their VM image.

Before raw-evidence-only storage, the reference run retained 4.5 MB of reports and 1.7 MB across 178 loose evidence files. Its canonical compressed JSON was 0.9 MB. The execution evidence alone packed to about 121 KiB; current archives also embed the exact denominator manifest and are the sole coverage artifact. Every CLI query derives its view from the archive. The first query builds a disposable integrity-bound binary index; later queries reuse it while the run identity remains valid. The index is an implementation detail and can always be deleted and reconstructed. These numbers are application- and filesystem-specific optimization baselines. An exact matching Vite build is also reused across runs, removing the measured 4.87-second repeated build; any source/configuration/toolchain-key change falls back to a fresh isolated build.

The evidence-only the reference application validation packed the exact manifest plus 178 execution-evidence files (2.66 MB uncompressed) into a 248 KiB archive. With the 4 KiB run.json, the complete immutable run occupies 252 KiB and contains no derived report. Its identical warm 29-test run recorded 0 ms for the build phase and 40.49 seconds total: 0.07 seconds initialization, 0.36 seconds workspace refresh, 0.05 seconds adapter setup, 39.84 seconds in the unchanged test command, and 0.12 seconds evidence validation/archive publication. Fresh process queries for summary, files, and gaps each took 0.16–0.20 seconds on this run before the reusable query index was introduced. Test execution is still the dominant and naturally variable part of the total.

Isolation strategy trade-offs

The safe default remains the transactional physical namespace. The intended optimization is an adaptive hybrid that selects a proven loader/plugin path and lazily materializes the same transactional fallback whenever an opaque runner needs real files. FUSE is not an appropriate portable default for a zero-install npx tool.