[llvm-dev] [cfe-dev] Who wants faster LLVM/Clang builds?
serge guelton via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 6 12:28:52 PST 2017
On Wed, Dec 06, 2017 at 11:38:54AM -0800, Michael Zolotukhin via llvm-dev wrote:
>
> > On Dec 6, 2017, at 9:00 AM, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> >
> > In my experience, a lot of time is spent on optimizing the code (assuming it's not a "-O0" build).
> The numbers were actually for the debug build (-O0 -g), so for Release build they would be different (presumably lower).
> > Also redundant includes are largely fixed by header guards, and I believe Clang [and gcc as well as MS Compilers, and probably most others too] have an include guards-cache that determines that "we've already included foo.h, and it has include guards around the whole actual content of the file, so we can just skip it”.
> By redundant here I meant that we included a file, but we didn’t use any of its content (rather than we included the same file twice).
> >
> > So I'm slightly dubious as to this being an efficient way of significantly reducing the total compilation time for the overall project - even if there are SOME cases where there is a significant improvement in a single file. The total time for a clean build [in wall-clock-time, not CPU-time] should be measured, making sure that there is enough memory. Doing a run of, say, five complete builds of the same thing [with suitable "clean" between to redo the whole build], take away the worst and the best, and perhaps also "modify one of the more common header files" (llvm/IR/Type.h for example) and build again.
> On full builds the benefit is not big (around 1%, but the noise is high), but: 1) if we only take gains more than, say, 5%, we’ll probably never see any, 2) I aim at changes that make the code strictly better (modulo David’s point about disk cache). If any change is questionable from maintenance or whatever other point of view, I’m all for dropping it.
my 2¢
+1 for point 2). Even leaving aside the speed gain, removing unused
includes file just looks like good coding practice to me.
More information about the llvm-dev
mailing list