Hall of shame: Header compilation times

[Magnus Ihse Bursie]

On 2022-09-06 13:01, Aleksey Shipilev wrote:
> On 9/6/22 12:31, Magnus Ihse Bursie wrote:
>> So, given this list, it seems like it would have a huge potential payoff
>> to start looking more closely on assembler.hpp. Is it strictly needed
>> everywhere it is included? Can it be split into multiple parts, so most
>> users only need to include some smaller subsets? Etc. And then
>> continuing doing the same with ciEnv.hpp and the top inline.hpp files...
>
> I agree it would be nice to comb through the includes and see what 
> could be trimmed down.
>
> But it would be weird to do major file splits for minor build time 
> improvements. This unfortunately has implications on long-term 
> releases maintainability, where backports would not be cleanly 
> applicable, the code archaeology would need to account for these 
> splits, etc.

Certainly! I do not claim to dictate how the hotspot folks wants to 
address it (or even if addressing it at all). Any changes must of course 
be reasonable. I only gave a few suggestions on the top off my head. 
However, I know from my prior experience that sometimes a header file 
can grow very large since it really covers too much. If that is the 
case, refactoring and breaking apart huge monolithic parts can be 
beneficial in many ways. But I do not know if that applies here.


>
> I think once we combed through the obvious over-includes, we could 
> just rely on precompiled headers to handle the rest? I just went and 
> added these to precompiled.hpp:
>
> +#include "asm/assembler.hpp"
> +#include "asm/codeBuffer.hpp"
> +#include "asm/macroAssembler.hpp"
> +#include "code/debugInfo.hpp"
> +#include "code/codeCache.hpp"
> +#include "oops/access.hpp"
>
> ...and got fairly reproducible improvements with PCH with GCC 9.4.0:
>
> Before:
>
> real    1m7.208s
> user    43m38.448s
> sys    3m15.264s
>
> After:
>
> real    1m6.801s
> user    42m6.183s  ; <-- about 3.7% improvement
> sys    3m19.828s
>
Interesting. That is certainly one way to use this information, so the 
expensive header files are at least only compiled once.

The result list has not only total time, but also average time and 
number of times included. Using the latter two, we can calculate a 
theoretical time saving for compiling a header file only once. This 
ordering might be slightly different from the total time spent, since a 
file that rather quick to compile but is included in many places can 
give a greater benefit to compile only once, than a "heavy" file that is 
included in just a few places, and the include count seems to go from 
~40 to ~700 in the data, so there is definitely some variance there.

/Magnus