(Taras told me to use sensationalist titles to draw more attention, so here we are)
Last week, I brought up the observable build times improvements on Linux try builds with the use of shared cache. I want to revisit those results now there have been more builds, and to look at the first results of the switch for Android try builds, which are now also using the shared cache.
Here is a comparison between the repartition of build times from last time (about ten days of try pushes, starting from the moment shared cache was enabled) vs. build times for the past ten days (which, almost, start at the point the previous data set stopped)):
As expected, the build times are still improving overall thanks to the cache being fuller. The slowest build times are now slightly lower than the slowest build times we were getting without the shared cache. There is a small “regression” in the number of builds taking between 15 and 20 minutes, but that’s likely related to changes in the tree creating more cache misses. To summarize the before/after:
|shared after 10 days||shared initially||ccache||shared after 10 days||shared initially||ccache|
[Note I’m not providing graphs for non-unified builds, they are boringly similar, with different values, which average and median values should give a grasp on]
Android try builds also got faster with shared cache. The situation looks pretty similar to what we observed after the first ten days of Linux try shared cache builds:
[Note I removed two builds without shared cache from those stats, both of which were taking more than an hour for some reason I haven’t investigated]
The fastest shared cache builds are, like for Linux builds, slower than the fastest ccache builds, and the slowest builds too, but as we can see above, those slowest builds get faster as the cache fills up. And as I wrote last week, work is under way to make the fastest builds faster.
This is what the average and median look like for Android try builds: