Improved precompiled headers support

Luboš Luňák l.lunak at
Tue May 7 09:32:10 UTC 2019


 at (and related changes) are 
patches that improve our PCH support. Most notably, it changes --enable-pch 
from all-or-nothing to several levels of what is included in the PCH. So if 
you previously didn't want to use PCH because it caused frequent large 
rebuilds, now you can use a smaller set that will generally avoid this. The 
levels are:

- --enable-pch=system - this includes in the PCH only system headers 
(including our externals). Since these generally should not change, generally 
the only visible difference to no PCH should be that things build faster. 
Interestingly, even just this makes a noticeable difference, ~10-15% for 
Clang (I guess STL headers are expensive).

- --enable-pch=base - this is like above, plus sal,osl,vcl. The logic is that 
if these change, it generally triggers a full rebuild anyway.

- --enable-pch=normal - this includes everything that the update_pch scripts 
finds worth it, except for headers from the module itself (i.e. 
precompiled_sc.hxx will not include anything from sc/inc). This should be 
suitable for people who limit their work to just one module. (BTW, "normal" 
is such a lame name, any better ideas?)

- --enable-pch=full - this is the old PCH setup, with everything suitable 
included, even from the module itself. It is (and used to be) the default 
with MSVC, and while it makes builds noticeably faster, I'm not sure how 
often a full rebuild is triggered. Is there somebody who develops on Windows 
who could tell?

 With the patches, the status should be:

- Clang works very well, including ccache. Interestingly large PCH levels 
don't seem to be worth it. I think at least --enable-pch=system could be even 
enabled by default. One small problem is that "clang -E -include-pch" 
apparently still loads the PCH, which means the preprocessing step of both 
ccache and icecream gets more expensive. If you have a larger icecream 
cluster, PCH may actually make things slower. Both of this is fixed by using 
recent tools, for ccache there's a new depend mode (see another mail), for 
icecream there's a fix at 
that hasn't made it yet into an official release. For openSUSE, you can get 
ccache and icecream from home:llunak:my repository.

- Given that MSVC's previous default was the same as --enable-pch=full, the 
only real change for MSVC should be that now you can limit the rebuilds if 
you want to. Given that --enable-pch=full gives a huge boost, I don't know if 
it's worth it changing the default, that would be up to people who use MSVC 
as their development setup.

- GCC seems to work, but since I use Clang, I haven't really tested it much or 
benchmarked it (feel free to do so). If a PCH needs to be rebuilt, it 
invalidates ccache and there seems to be no easy way to change that. A 
non-trivial one could be to use the CCACHE_PCH_EXTSUM support in and instead of using sha256sum on the PCH file to 
create the .sum file the sha256sum could be run on the result of 'gcc -E 
pch_file'; I think that would work, but I'm not going to implement that 

- Since usage of PCH means more header files are included that are specified 
in the .cxx itself, using PCH can occassionally result in build failures when 
PCH is not used because of missing #include somewhere (which Gerrit should 

 Some numbers:

MSVC make

Clang make
7787.87user 338.38system 17:16.07elapsed 784%CPU
6855.09user 317.00system 15:14.63elapsed 784%CPU
6053.77user 292.01system 13:44.17elapsed 769%CPU
5630.99user 291.14system 12:49.84elapsed 769%CPU
6594.09user 342.08system 15:02.78elapsed 768%CPU

Clang (+icecream) make
2567.16user 153.31system 6:06.06elapsed 743%CPU
2459.44user 154.33system 5:45.65elapsed 756%CPU
2348.35user 145.39system 5:34.80elapsed 744%CPU
2222.20user 145.31system 5:19.22elapsed 741%CPU
2439.10user 156.82system 5:53.10elapsed 735%CPU

Clang make
516.32user 25.69system 1:12.03elapsed 752%CPU
358.46user 20.67system 0:52.50elapsed 722%CPU
304.94user 19.14system 0:45.63elapsed 710%CPU
300.30user 19.27system 0:43.08elapsed 741%CPU
274.82user 19.56system 0:42.65elapsed 690%CPU

 Luboš Luňák
 l.lunak at

More information about the LibreOffice mailing list