base: speed up local rebuilds. #103
Conversation
Using ccache can speed up local rebuilds even when the container layer
cache is invalidated, which is easy to happen. It also requires a less
complicated and less fragile setup than distcc (though distcc will
always make for faster first builds).
install_epics.sh still supports ccache-less setups, should that be
required.
On my machine, building an image with ccache for the first time took
~15m. Rebuilding it after invalidating the layer cache took only 4m06s.
The output of 'ccache -s' is reproduced below:
Cacheable calls: 1929 / 4371 (44.13%)
Hits: 1923 / 1929 (99.69%)
Direct: 1829 / 1923 (95.11%)
Preprocessed: 94 / 1923 ( 4.89%)
Misses: 6 / 1929 ( 0.31%)
Uncacheable calls: 2442 / 4371 (55.87%)
Local storage:
Cache size (GB): 0.19 / 5.00 ( 3.71%)
This was based on StackOverflow [1], but adding the compiler symlinks to
/usr/local/bin wasn't enough for the EPICS build system to use them,
since it uses fully qualified paths. Therefore, it was necessary to
override the paths in configure/CONFIG.gnuCommon (appending to the file
was the easiest way to override them for sure). We also had to call
'ccache -z' to remove the ccache statistics file, otherwise it would
roll over for each build and mix data from different builds.
[1] https://stackoverflow.com/a/56833198
|
I'm using Having those files in the build image shouldn't be an issue anyway, since all our images use multi-stage builds with copies into a clean image. |
In fact, it doesn't make much sense to have it as an
I'm not sure I grasped which files you're referring to. Are you talking about not defining |
Using ccache can speed up local rebuilds even when the container layer cache is invalidated, which is easy to happen. It also requires a less complicated and less fragile setup than distcc (though distcc will always make for faster first builds).
install_epics.sh still supports ccache-less setups, should that be required.
On my machine, building an image with ccache for the first time took ~15m. Rebuilding it after invalidating the layer cache took only 3m36s. The output of 'ccache -s' is reproduced below:
It is not clear why the cache hits were below 50%, but it was still enough to make a big difference in build times.
This was based on StackOverflow [1].
[1] https://stackoverflow.com/a/56833198