> I was really wondering how did you achieve the 375% speed boost of
> building. Will you share it here?
In the end, it is rather primitive.
The problem of build speed is caused by long headers. GCC parsing header is
faster than compiler parsing implementation + generating debug code, but
still pretty slow. Now if average file size is about 1000 lines, then
average number of header lines is at least 10000 lines (some of out
high-level files include as much as 100000 lines of headers). So it is
pretty clear that headers make build slow.
OTOH, most files include pretty much same headers. And most headers are
prevented against multiple includes by #ifdef/#define guards.
So what I do is to determine whether all headers included by specific file
in group of files are "guard locked" (by scaning headers - I need to scan
them in our builders code anyway to determine header dependencies). For
files that are approved (for staying at simple level, let us consider
'clean' build for now) I form something I call 'BLITZ' batch, that is file
and compile it instead of individual files. Now compiler has to parse
headers just once - and awesome speed gain is here...
There are of course caveats. Some of them are serious (like defining static
function with same name in two files), some can be cured (like #define
macros in file - I scan files for such macros and place #undefs to BLITZ
batch). To solve more complicated cases, I have also introduced #pragma
BLITZ_PROHIBIT and #pragma BLITZ_APPROVE....
Another problem is of course unclean build - that is, rebuilding just one
file. For that I have added some heurestics which basicaly work by excluding
files which you work on from BLITZ batch. Well, sometimes it means that when
you start work on a single file, blitz batch has to be recompiled too (even
if files are otherwise unchanged), but in the long run this is not a