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

[Michael Zolotukhin via cfe-dev]

I agree with you regarding the transitive includes. However, what’ I’m trying is different: I would like to remove headers that are included directly, but not used. Ideally, I’d like not to remove headers that are included transitively. The current patch has such removes because my tool was intended to just point us to files which can be cleaned-up and suggest a way to do it. The original idea was that we then take a look at interesting files and manually remove unnecessary headers after manual inspection.

I see though how having such removes in the patch leads the conversation to transitive headers/symbols forward declaration/etc (which I don’t plan to touch at the moment), so I’ll try to improve my tools so that they produce a cleaner patch. Stay tuned!

Thanks,
Michael

> On Dec 6, 2017, at 1:17 PM, Matthias Braun <mbraun at apple.com> wrote:
> 
> - We do indeed have a lot of unnecessary includes around in llvm (or pretty much any other C++ project for that matter).
> - I want faster builds.
> - The only way to reliably fight this is indeed automatic tools.
> - Having the right amount of includes also has documentation value and ideally let's you understand the structure of your project.
> - However relying on transitive includes works contrary to the last "undestanding/documentation" point.
> - (And as stated earlier to have things really clean we want `class XXX;` instead of `#include "XXX.h"` wherever possible. And if you are serious about that we also often have to reduce the amount of include code in the headers so we can move the `#include "XXX.h"` from the header to the implementation.
> 
> For me personally I think the documentation/understandability we loose when relying on transitive includes weights heavier than my desire to get a faster build...
> 
> - Matthias
> 
>> On Dec 6, 2017, at 12:28 PM, serge guelton via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 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 <mailto: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.
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171206/6efb0529/attachment.html>