Reduce repeated process and build-graph startup

Batch compatible test work or share its build graph to avoid paying process startup and initialization for every file or target.

View in Markdown

Prompt

Evaluate and apply this CI technique to my repository: Reduce repeated process and build-graph startup.

Batch compatible test work or share its build graph to avoid paying process startup and initialization for every file or target.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/reduce-test-process-overhead.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How companies used this technique

Read what each company changed and follow the original sources.

Run reliable test files in one parallel invocation per shard

Each Bun test shard now runs its fast, historically reliable test files as one bun test --parallel batch, an invocation that distributes the files across a pool of worker processes, where each file used to start its own process. Files that have shown batch sensitivity go on a denylist and run on their own, and so do memory-measuring tests.

Per-lane test shard time for the whole change (batching, the full core count on test agents and one up-front addon build per shard), one main build against one branch build: debian x64-asan 8.5 to 4.9 minutes on average (42% lower), windows 2019 x64 8.6 to 6.0 minutes (30%), darwin 26 aarch64 15.5 to 12.6 minutes (19%). Source

Use it when: Process startup for each test file takes a large share of a big suite, and a reviewed set of files shares no mutable state.
Before applying it: Files in unlisted directories stay on the per-file path, and a new test file in a listed directory joins the batch; the batch reports every file it runs, and any error in the batch turns the job red.

Run tests in fewer processes

Codex moved every integration test under tests/ into one suite, so cargo builds and starts a single test binary. The Python SDK compiles its dependency-policy checker once per pytest worker and runs each of its policy cases in-process with fresh globals, keeping real subprocess tests for CLI parity.

Python 3.14 test job: 7m00s to 2m41s (2m24s before the policy matrix landed) Source

Use it when: A suite repeatedly starts interpreters, CLIs or separate test binaries.
Before applying it: Sharing a process can expose leaked state and environment changes. Keep tests isolated and compare results as well as runtime.

How companies used this technique

Run reliable test files in one parallel invocation per shard

Run tests in fewer processes

Build related test targets in one graph

Related techniques

Let an agent break import cycles and make the app load lazily

Share module initialization only for explicitly safe tests

Balance test work across shards

Company Playbooks

Related guides

Cut repeated test setup

Shard tests across parallel jobs

Diagnose slow tests in CI

Optimize Playwright tests

Make Vitest run mode explicit