Re: speeding up compile times in C++

amichail@cs.toronto.edu (Amir Michail) says:
>Would this idea work? Would it improve compilation times?


Guy L. Winterbotham <glwinter@infi.net> writes:
> For a commercial slant on this idea look at Borland C++ which makes use
> of precompiled headers. As long as you can keep the .h files needed
> by your project to a known set it makes a hugh difference to compile
> time.


and Taylor Hutt <thutt@clark.net> writes:


> Why is it that the concept of a symbol file is so hard for C++ programmers
> to understand? This problem has been solved for quite a long time with
> languages using a real module structure yet, despite this fact, C++
> programmers and writers continually propose new solutions ranging from
> wrapping anonymous structure pointers (read: opaque types) in the main
> header file (so the implementation can be changed at will) to the idea
> proposed here.


Well, our project is nearly 1 million lines of C++. We have thousands of
classes but only use `standard' C++ techniques (not including headers
whenever possible, using forward declarations etc.) and do not use
`clever' declaration techniques such as opaque types.


We too have hit the dumb compiler/language problem. Our cfront compiler
spent most of the *very* long build process contructing symbol tables for
included classes. So, we did an experiment:


Rather than separately compile individual files and then link into a
library or program we used the preprocessor. We #include all the sources
for a library into one source file and compiled that as a whole.


The purpose of this approach is to ensure the compiler reads a class
declaration once only. The result? Compile/link times were cut to 1% of
those using the conventional separate compilation/linking approach.
However, there are potential problems, the possible quiet redefinition of
macros and a change in the meaning of static (which essentially becomes
extern since `file' scope is now the whole lib/program).


Since we had such significant benefits at very little cost this has become
a key technique for quickly building large libraries. The results
suggests symbol files have many advantages for C++, especially since
parameterised types already require the compiler to hold some information
across separate compilations.


Hopefully, someone out there in cfront land will take note of Taylor's
comments because us C++ users *need* a proper solution and not yet another
bodge ;-)


Steve
--

Return to the comp.compilers page.
Search the comp.compilers archives again.