JobCache is a built-in feature of CloudBees Accelerator that intelligently analyzes past compilation tasks along with recent changes, and then smartly reuses object files that aren’t affected by any of the recent changes. This can trim CloudBees Accelerator build times by an additional 40% using the same build hardware. In addition, JobCache can reduce capital expenditure (CapEx) and operational expenditure (OpEx) while maintaining the same build speeds with fewer machines.
How it works
JobCache lets a build avoid recompiling object files that it previously built if their inputs have not changed. JobCache works even after you clean the build output tree (for example, by using “make clean”). By caching and reusing object files, JobCache can significantly speed up full builds.
JobCache uses cache “slots.” When JobCache is enabled, eMake (CloudBees Accelerator’s version of make) maintains a slot for each combination of command line options, relevant environment variable assignments, and the current working directory. A slot can be empty or can hold a previously-cached result. If the appropriate slot holds an up-to-date result, a cache “hit” occurs, and compilation is avoided.
A cached result becomes obsolete if eMake detects file system changes that might have caused a different result (with the same command line options, environment variable assignments, and current working directory). Such file system changes include any files that are read during compilation, which means all source files, GCC precompiled headers and compilation tools included in the eMake root.
How it is different
CloudBees Accelerator JobCache is 20% to 50% faster than ccache on Android builds. In the graph below, using 24 processing cores, CloudBees Accelerator with JobCache (eMake w/ JobCache) takes less than half the time as gmake with ccache on 64 cores.
The benchmarks were created using Android M, gmake using 64 cores and ccache, and CloudBees Accelerator using 24 cores.
JobCache is designed for reliability so that it can even be used for production builds. ccache has known shortcomings that can cause it to produce false positives making it risky to use on production builds.
JobCache is more flexible. ccache works only when gcc produces .o files. However, gcc can generate other files as a side-effect of compilation, like profiling data and debug symbols. ccache typically just refuses to cache compilations when those features are enabled. JobCache will cache even when these features are enabled and other files are generated.
CloudBees Accelerator and JobCache also make it easier to identify build bottlenecks and to further accelerate your builds through a rich visual user interface — making performance and cache miss analysis trivial. When a cache miss occurs in ccache, it is nearly impossible to figure out why.
JobCache also is more collaborative with its Shared JobCache capability allowing multiple users to share the contents of the cache, eliminating costly and redundant efforts of rebuilding unchanged modules across the whole team. Rather than just store object files in a local cache for individual developers, Shared JobCache stores them in a shared cache for everyone’s benefit. Multiple developers can now reuse the build output from a golden build by simultaneously accessing the common (shared) cache in read-only mode — making them more productive and improving overall quality. Everyone is now assured of using modules from the latest build. Ccache has only rudimentary sharing capabilities with no quality guarantees.
Faster builds or less hardware?
For many users, build acceleration is a key goal. Using CloudBees Accelerator users can achieve additional build acceleration by putting more computing resources into the build farm and/or using JobCache.
However, for some users throwing more hardware at the problem isn’t feasible from a CapEx cost perspective. For others, reducing the OpEx costs (e.g. real estate, cooling, electricity) of maintaining large build server farms may be a business objective. In this case, JobCache can also be valuable by allowing build speeds to be maintained using fewer computing resources. In the example below, a build on 16 cores using JobCache is faster than a build on 64 cores not using JobCache.
About CloudBees Accelerator
CloudBees Accelerator is a build and test acceleration platform for make-based, Android AOSP, Embedded Linux, BitBake, and Visual Studio build environments that intelligently and automatically parallelizes software tasks across clusters of physical or cloud CPUs to dramatically lower build and test cycle times.