You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DB tests: Istanbul coverage adds ~50% wall time / ~38% CPU to the packages/db suite #2274
In packages/db, coverage is on by default (vite.config.ts: coverage: { enabled: true, provider: 'istanbul', include: ['src/**/*'] }), so every local pnpm test run pays for instrumentation. I measured the cost on the full suite:
Environment: Apple M3 Max (16 cores, 128 GB), Node v26.12.0, pnpm 11.1.0.
Goal
Reduce test overhead while keeping the same coverage and checks that CI enforces today. CI collects DB coverage per shard and merges it with vitest --mergeReports in .github/workflows/pr.yml, and that should keep working.
Possible directions (for discussion)
Turn coverage off by default for local runs and enable it explicitly in scripts/ci-tests.mjs / CI, so CI coverage doesn't change.
Compare provider: 'v8' with Istanbul for overhead and report parity before considering a switch.
I'm happy to do the follow-up PR, with before/after numbers, once there's agreement on a direction.
Follow-up: here is where the rest of the cost goes, beyond coverage.
Method. I ran packages/db with --maxWorkers=4, changing one condition per run. Times are wall time and total CPU (user+sys). I measured on commit 26d38a4cd with Node 26.12.0, on an M3 Max. A repeated run of the same condition matched within 0.02 s. On Node 24.18.0 with origin/main + #2275 (300 files), the coverage cost has the same shape: 122 s / 421 s without coverage, 165 s / 522 s with it.
Cost
Wall
CPU
Kind
Istanbul coverage
+43–48 s
+100–140 s
Instrumentation
tests/oracle-replay.test.ts
+20 s
+106 s
Process startup
typecheck: { enabled: true }
+26 s
+35 s
tsc
environment: 'jsdom' for all files
+15 s
+76 s
Environment setup (~75 of 285 files touch the DOM)
oracle-replay.test.ts runs 38 tests. Each one calls spawnSync to start node --import tsx tests/oracle-replay.ts, which spawns vitest run. One replay costs about 1.7 s, and Vitest's own work is 0.55 s of that. The rest is process startup. The file runs serially in one worker for 77 s, which sets a floor on the suite's wall time.
Activity
jp-knj commentedon Oct 28, 2026
Follow-up: here is where the rest of the cost goes, beyond coverage.
Method. I ran
packages/dbwith--maxWorkers=4, changing one condition per run. Times are wall time and total CPU (user+sys). I measured on commit26d38a4cdwith Node 26.12.0, on an M3 Max. A repeated run of the same condition matched within 0.02 s. On Node 24.18.0 withorigin/main+ #2275 (300 files), the coverage cost has the same shape: 122 s / 421 s without coverage, 165 s / 522 s with it.tests/oracle-replay.test.tstypecheck: { enabled: true }tscenvironment: 'jsdom'for all filestests/indexed-db/retirement-oracle.test.tsNotes:
oracle-replay.test.tsruns 38 tests. Each one callsspawnSyncto startnode --import tsx tests/oracle-replay.ts, which spawnsvitest run. One replay costs about 1.7 s, and Vitest's own work is 0.55 s of that. The rest is process startup. The file runs serially in one worker for 77 s, which sets a floor on the suite's wall time.Next I'm looking at reducing the replay test's process startup without weakening what it checks.