[llvm-dev] Who wants faster LLVM/Clang builds?

[Michael Zolotukhin via llvm-dev]

> On Dec 6, 2017, at 12:45 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> On 5 Dec 2017, at 23:40, Mikhail Zolotukhin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> The list of files for which removing redundant headers improved compile time (the numbers are compile time in seconds for a Debug build):
> 
Thanks for the comments! I agree with all the points you brought up, and actually I thought about most of them before, please find my comments below:

> A few comments:
> 
> First, your old and new numbers are giving time to a hundredth of a second, yet I generally see a variation of 0.1-0.2 seconds between runs.  How many times did you run each one and what is the Welch’s t-test delta?
I measured the time 5 times for both ‘old’ and ‘new’ versions and took the minimum. I don’t have variance and other statistics at hand now, but I’m pretty confident in the ballpark of the numbers. I.e. If the number goes from 1.7s to 1.1s, I’m pretty sure there is a win (even if the ‘true’ numbers would be 1.6 and 1.2 respectively).
> 
> Second, most of the changes are a few tenths of a second.  From the whole of your top 10, it looks as if you’re shaving around 3 seconds off the total build.  Presumably this is CPU time, so on a -j8 parallel build you’re saving under a second for something that takes a few minutes.  That doesn’t mean it’s not worth doing, but it does mean that if it has any impact on code maintainability then it probably isn’t.
Correct. That’s exactly why I aimed for small local changes that would be a strict improvement over what we have now. Also, while the effect on the total build time isn’t big, incremental builds can see much more significant gains from it.

> Third, it’s not clear from your measurements whether you were doing a modules build or not.  The cost of redundant includes should be a lot lower if we’re using modules.
No, I didn’t do modules, and yes, you are correct (and this is another argument for probably not spending more efforts here).
> 
> Finally, redundant includes can have a counterintuitive positive benefit on overall build times by warming the buffer cache (pulling in an include early when the dependency graph for the build is wide lets another compile job proceed while you’re waiting for disk, whereas pulling it in later when you’ve exhausted the parallelism in the build process causes a synchronous stall).  Did you measure the deltas in overall build time for a cold and warm disk cache after making these changes?
No, I didn’t measure it with cold and warm caches. For the entire build (-j8) I usually saw a win of ~1%, but that number is even more noisier, so I didn’t report it. However, I’m a bit sceptic about keeping redundant includes to prefetch them to cache. There is no guarantee that a file with the redundant include will be compiled first, and if it’s compiled after we’re just wasting our time. There are also other files that actually need this header and will move it to the cache before our use, so all in all I don’t think the positive effect of having redundant includes outweigh its cost.

Thanks,
Michael
> 
> David
> 
>