Is a remote build cache worth it?
On the small projects we measured, a filled cache took about a quarter off a Gradle build, and an empty one cost about a second. Here are the numbers and the runs that produced them. They are from our test projects on a CI machine, so measure your own.
Gradle: what a cache saved and what a miss cost
We ran the same Gradle build three ways, seven times each, and timed the whole command.
| Setup | Fastest | Median | Slowest |
|---|---|---|---|
| No remote cache | 17.06 s | 17.54 s | 18.17 s |
| Remote cache, empty (a miss) | 16.83 s | 18.54 s | 18.67 s |
| Remote cache, filled (a hit) | 12.79 s | 13.41 s | 13.60 s |
By the medians, a miss cost about one second (about 6%) and a hit saved about four (about 24%). The miss build was slower in 6 of 7 rounds. The run and its log are public.
What we ran: a GitHub-hosted CI machine, 4 vCPUs, 16 GB; Gradle 9.8.0, Java 21; FosterStack Cache 0.2.1 on the same machine. The project had 4 modules of 150 generated classes each, and only the compile tasks ran. It compiles quickly and every build also paid Gradle's start-up, so a bigger project may show different percentages. Details: does a remote cache slow your build when it misses?
Maven: what gets restored
For Maven we recorded which modules were restored from the cache and which were built, on a three-module project with Apache's Build Cache Extension. We have not published a Maven timing table, so there is no Maven time saving on this page.
| Build | core | util | app |
|---|---|---|---|
| First build, as CI would do it | built | built | built |
| Another machine, same code | restored | restored | restored |
| Edit inside a method in core | built | built | built |
| A teammate makes the same edit | restored | restored | restored |
| Edit only app | restored | restored | built |
| Edit only util | restored | built | built |
The first person to make a change pays for it; everyone after restores the result. The run and its log are public. Details: Maven Build Cache Extension in a multi-module project.
What this tells you, and what it does not
- A cache that is empty or down makes builds slower, not wrong. See what happens when the server is down.
- Results are from small test projects on one kind of CI machine. We did not test large projects or other CI products.
- Your saving depends on how much of your build is work that can be skipped. Turn it on in CI first, then read your own hit rate: how to measure it.