A fresh CI runner has no run history, so the history scheduler guessed. Now one JSON file carries the learned times from runner to runner.
Performance
Performance
@vzn/vx-schedule-history starts the longest chain first, using task
times from past runs. A fresh CI runner has no past runs, so the first
run on every runner fell back to a guess.
A graph where order matters: eight packages whose build, check and
pack chain unlocks more work (0.5 s each), and three slow e2e tasks
(10 s each) that nothing depends on. Every task runs; only the order
changes.
Wall time (min of 3)
Cold, no file12.09 s
Cold, with the file10.68 s
Full local history10.64 s
The table
Runner
Wall time (min of 3)
Cold, no file
12.09 s
Cold, with the file
10.68 s
Full local history
10.64 s
With no times, the slow tasks start last. The file starts them first,
cutting 12% off the wall time and matching a machine with its full
history. The lower bound here is 10.5 s.
Setup: linux x64, 4 cores, 4 workers, sleep tasks, vx 0.0.634. Run it
yourself with bun packages/vx-bench/timings-file-bench.ts.
When one task is the whole wall time, order cannot help. vx’s own CI job
is like that: one 194 s test suite set its time with and without the
file (194.07 s and 194.60 s).
A run that executed nothing and restored only tasks the file already
times leaves the file alone, so an all-cached CI run pays no extra history
read. Runs that use no history plugin do no extra work.
On a cold run every cache lookup misses, so vx no longer asks. The first task of a 1,090-package build now starts in about 230 ms, down from about 380 ms earlier the same day.
One line in vx.workspace.ts picks which ready task starts first when there are no timings yet. The default is unchanged, and a history plugin still leads.
When more tasks are ready than workers, a runner has to pick. Five rules for picking, the graphs where each one wins and loses, measured with vx, and why recorded timings beat every rule that has to guess.
Turborepo, Nx and other product names are trademarks of their owners. vx is not affiliated with or endorsed by them.