Re: Precompiled headers do not speed compilation up?

[Bernd Strieder]

Hello,

Markus Dehmann wrote:

> 
> // main2.cpp
> #include "all.h"
> int main(){
>   std::cout << "hello";
> }
> // all.h
> #include <iostream
> #include "header1.h"
> #include "header2.h"
> #include "header3.h"
> 
> // On the command line:
> $ g++ all.h
> $ g++ -c -o main2.o main2.cpp

I don't think this is the real example taking 40 sec, and therefore you
cannot see the point here.

> Why would precompiling the header not help in this situation? Am I
> doing it wrong?

Since precompiled headers have some overhead, you will never have an
advantage from using precompiled headers with a single or only a
few .cc files, or when using precompiled headers only a few times. With
many .cc files the overhead is over-amortized to a net win. So let's
assume you have many .cc files.

If you use a header file like the all.h including all your header files,
but most of your .cc files only use a small fraction of all.h, then
reading the precompiled header can become slower than reading and
parsing the non-precompiled but minimal set of headers needed for a
particular .cc file. To get the optimum out of precompiled headers you
will possibly have to use several different ones, not a single all.h.
And you will have to find good candidates of sets of header files,
which is combinatorically catastrophic.

I have found precompiled headers not worth the effort in development of
my projects, i.e. the edit-compile-debug cycle. Since release build are
pretty rare compared to that, I do not have a good use for precompiled
headers as they are implemented now.

AFAIK there are quite some ideas to improve precompilation to the point
where I think they would give an overall advantage. I think introducing
some gcc daemon to control compilation of many units at once has a lot
of opportunities. There is work in progress on this on the linking
side, so maybe it's worth to look at it from the other side as well.


Bernd Strieder