Benchmarks
All numbers are dev (unoptimized) builds, wall clock, measured on 2026-11-13 on tempo, reth and pyramid. The short version: a new checkout goes from minutes to seconds, the first build costs a few percent more, and the edit loop gets faster from settings rather than the cache.
A new checkout, after someone has built once
A "new checkout" is a second copy at another path with an empty target directory: what a new clone, a new worktree or another agent's machine sees.
Another machine, from a shared box
The box built tempo and reth once with a trusted token. Each client started with an empty local store and target directory.
Over a real link, the wire decides. One request per file moved tempo's 8.1 GB at 61 MB/s, slower than compiling. With the prefetch (16 streams, zstd), tempo's 8.7 GB went as 1.9 GB in 10.2 s.
The first build costs a little more
| Target | cargo cold | shippy cold |
|---|---|---|
| tempo | 127.8 s | 135.3 s |
| pyramid backend | 374.7 s | 400.8 s |
| reth | 111.3 s | 112.5 s |
That 6 to 7% is hashing and storing about 1,000 results, and packing build-script output (rocksdb's OUT_DIR alone is 1.7 GB).
Rebuild after an edit
tempo, median of 3 runs, geometric mean of three edits that recompile 1, 4 and 15 crates.
| Variant | Geometric mean | Against cargo |
|---|---|---|
| cargo | 10.05 s | 1.00x |
| shippy, default settings | 10.17 s | 0.99x |
| tuned, stable: wild, no debug info | 6.77 s | 1.48x |
tuned, nightly: + -Zthreads=8 | 5.40 s | 1.86x |
| tuned, nightly + Cranelift for workspace crates | 5.33 s | 1.88x |
The wrapper alone changes nothing on a first edit, as expected. Undoing an edit is where the cache shows: with linked outputs cached, putting the file back took cargo 3.6, 11.4 and 21.0 s, and shippy 1.3, 2.1 and 2.5 s.
Trusted and untrusted writers
tempo, one box, four people with empty machines and different checkout paths, building one after another:
| Who | Token | Build | Restored from the box |
|---|---|---|---|
| alice | untrusted | 158.6 s | 0 |
| bob | untrusted | 120.9 s | 962 |
| ci | trusted | 118.3 s | 968 |
| carol | untrusted | 58.6 s | 1,063 |
The box re-ran alice's 993 compilations in its sandbox and published 991, finishing 28 s after her build. Nothing alice uploaded was served to bob: he got what the sandbox produced.
Machines
| Name | CPU | Memory | Disk |
|---|---|---|---|
| xeon | Xeon Gold 6526Y, 32 threads | 126 GB | ext4 on md RAID |
| hand | 5 cores, Pyramid hosted Hand | 14 GB | ext4 |
| box | 48 cores, Frankfurt | 377 GB | tmpfs |
What to do with this
- Use tuned settings: tune a project.
- Keep the store and target directories in memory, or on a filesystem with reflinks.
- Set
SOURCE_DATE_EPOCHfor dev builds of projects whose build scripts stamp the time. - Leave linked outputs cached, and give the store a size that fits its disk.
- Put the box near the builders. The prefetch makes a far box usable (19 s across the Atlantic); a near one is 8 to 14 s.
Go deeper
- docs/measurements/2026-11-13.md: every table, with the commits and methods.
- docs/measurements/2026-11-14.md: where the time of a build that restores everything goes, on tempo.
- docs/measurements/2026-11-15-together.md: one pass with everything in one binary: a first build beside the box, another user's fresh machine, edits after priming.