Stop using precompiled headers for Linux?

Magnus Ihse Bursie magnus.ihse.bursie at
Thu Nov 1 17:24:45 UTC 2018

> 1 nov. 2018 kl. 17:49 skrev Erik Joelsson <erik.joelsson at>:
>> On 2018-11-01 08:17, Magnus Ihse Bursie wrote:
>>> On 2018-11-01 15:53, Ioi Lam wrote:
>>> Just a stupid question. Does GCC have actual support for PCH? I know windows can load pre-compiled information from a special binary file. Does GCC support that kind of functionality?
>> Yes.
> But the Visual Studio compiler seems to be able to gain much more build performance from it. I don't have fresh numbers but I definitely remember a non PCH build on Windows taking more than double the time, if not triple or quadruple.

Could that be due to a lower starting point? I mean, if the windows compilation takes more time in the base case, it's easier to improve times with PCH. 


> /Erik
>> /Magnus
>>> Thanks
>>> Ioi
>>>> On Nov 1, 2018, at 5:09 AM, Magnus Ihse Bursie <magnus.ihse.bursie at> wrote:
>>>>> On 2018-11-01 12:51, Thomas Stüfe wrote:
>>>>> On Thu, Nov 1, 2018 at 12:05 PM Magnus Ihse Bursie
>>>>> <magnus.ihse.bursie at> wrote:
>>>>>> On 2018-11-01 11:54, Aleksey Shipilev wrote:
>>>>>>>> On 11/01/2018 11:43 AM, Magnus Ihse Bursie wrote:
>>>>>>>> But then again, it might just signal that the list of headers included in the PCH is no longer
>>>>>>>> optimal. If it used to be the case that ~100 header files were so interlinked, that changing any of
>>>>>>>> them caused recompilation of all files that included it and all the other 100 header files on the
>>>>>>>> PCH list, then there was a net gain for using PCH and no "punishment".
>>>>>>>> But nowadays this list might be far too large. Perhaps there's just only a core set of say 20 header
>>>>>>>> files that are universally (or almost universally) included, and that's all that should be in the
>>>>>>>> PCH list then. My guess is that, with a proper selection of header files, PCH will still be a benefit.
>>>>>>> I agree. This smells like inefficient PCH list. We can improve that, but I think that would be a
>>>>>>> lower priority, given the abundance of CPU power we use to compile Hotspot. In my mind, the decisive
>>>>>>> factor for disabling PCH is to keep proper includes at all times, without masking it with PCH. Half
>>>>>>> of the trivial bugs I submit against hotspot are #include differences that show up in CI that builds
>>>>>>> without PCH.
>>>>>>> So this is my ideal world:
>>>>>>>    a) Efficient PCH list enabled by default for development pleasure;
>>>>>>>    b) CIs build without PCH all the time (jdk-submit tier1 included!);
>>>>>>> Since we don't yet have (a), and (b) seems to be tedious, regardless how many times both Red Hat and
>>>>>>> SAP people ask for it, disabling PCH by default feels like a good fallback.
>>>>>> Should just CI builds default to non-PCH, or all builds (that is, should
>>>>>> "configure" default to non-PCH on linux)? Maybe the former is better --
>>>>>> one thing that the test numbers here has not shown is if incremental
>>>>>> recompiles are improved by PCH. My gut feeling is that they really
>>>>>> should -- once you've created your PCH, subsequent recompiles will be
>>>>>> faster.
>>>>> That would only be true as long as you just change cpp files, no? As
>>>>> soon as you touch a header which is included in precompiled.hpp you
>>>>> are worse off than without pch.
>>>>>> So the developer default should perhaps be to keep PCH, and we
>>>>>> should only configure the CI builds to do without PCH.
>>>>> CI without pch would be better than nothing. But seeing how clunky and
>>>>> slow jdk-submit is (and how often there are problems), I rather fail
>>>>> early in my own build than waiting for jdk-submit to tell me something
>>>>> went wrong (well, that is why I usually build nonpch, like Ioi does).
>>>>> Just my 5 cent.
>>>> I hear you, loud and clear. :) I've created to disable PCH by default, for all builds, on gcc. (I'm interpreting "linux" in this case as "gcc", since this is compiler-dependent, and not OS dependent).
>>>> /Magnus
>>>>> ..Thomas
>>>>>> /Magnus
>>>>>>> -Aleksey

More information about the build-dev mailing list