Why vx is fast: five decisions, not a trick
Why vx is fast: five decisions, not a trick
What vx adds to a run with nothing changed, with no daemon, and the five design choices behind that number.
// the vx blog
Posts tagged internals.
Why vx is fast: five decisions, not a trick
What vx adds to a run with nothing changed, with no daemon, and the five design choices behind that number.
Your cache key is already in git's index
vx reads file hashes from git's index instead of reading your files: 2.3 ms for 2,527 files. A commit never changes a key.
Hash what the config turns into
vx hashes your config after it runs. Change a preset you import and every task that uses it gets a new key, with no list to maintain.
Every cache key is known before anything runs
A task's key includes its dependencies' input keys, never their outputs. So every key in the graph exists before the first task starts.
Task priority in milliseconds, not 8.5 seconds
On a 3,270-task graph, task priority took 8.5 seconds with set unions. Bitsets do it in single-digit milliseconds, and cache restores never take a slot from a build.