One implication of this is that if one of the header files is changed, any cpp file that uses that header file or cpp file that uses a header that uses the changed header is going to need recompilation.
Further, lots more is happening during compile for C++ as compared to Java, where more happens at run-time. Depending on their extent of usage, templates can consume measurable compile time. Extensive optimization can cause measurable increase in compile time.
Also contrast the compile time you get with go, which is ridiculously faster than C++ when measured by the edit-compile-link-run cycle.
I am now of the opinion that the C++ compilation model is broken, or more charitably, has been shown to not have learned from the compilation models of the following languages:
* python * ruby * go * java and other jvm uses such as clojure * and many others
despite what Herb says about how modern c++ is.
When you use a virtual machine, much of the machine code required to execute the resulting program has already been compiled. Some languages/runtimes also use a JIT to compile code at runtime instead of build-time.
I think that both are correct. But it should be noted that what you call a lack of learning, is really quite deliberate. Since it began, one of the design constraints of C++ has been almost total backward compatibility with C. That means that C++ is permanently stuck with a 40-year-old compilation model.
You may have an include file that gets touched/changed a lot, and that shows up (directly or indirectly) in most of your project files. Have a look at your dependency tree and see if anything jumps out at you. Alternately, you can "touch" a few files at a time manually, re-build, and try to track down a culprit that way.
Also, take a look at John Lakos' "Large-Scale C++ Software Design", which offers metrics and design guides for reducing dependencies among files in a project.
Assuming you have no way to get around each source file including lots of headers, many C/C++ build tools offer some kind of "pre-compiled header" option, that you might look into.
Finally, check to see whether you're doing a very aggressive "release" build, with lots of inter-procedural optimizations enabled. I find IPO at the link stage takes a very long time. So compare your debug build options against your release build options, and think about what the timing differences tell you.
Presumable I should really do a side by side comparison for a project of the same LOC but I always had the subjective feeling
> You may have an include file that gets touched/changed a lot
I more meant an initial clean&compile step
> "pre-compiled header" option
what do you mean here?
> Finally, check to see whether you're doing a very aggressive "release" build,
ok, this could be one cause, yes
I don't know all the details, but consider that the compiler has to read the header file, parse it, make a map of its contents (its declarations and #defines and type definitions and so forth). And it has to do that over and over, for every source file that includes that header.
So if the compiler stashes away a binary representation of the contents of that header, then it can skip the slow bits of reading the text file and figuring out its contents and all. It only has to do that the next time you change the header.
edit: See http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
Java, I believe, essentially does this already, because it turns each .java file into a .class file (or whatever, it's been a while). And that .class file contains all the information that other java sources need in order to know what's in that java file.
Fortran-90, a language that gets no love on Hacker News, has a nice module facility that also enables this. Module information can get stored in a binary form that other sources can look into without having to re-parse the original text file.
Going back to C/C++, though-- if your root problem is that you have big header files that appear everywhere and slow down the compilation of every module, then you may want to think about reorganizing your code to reduce dependencies. Pre-compiling the headers may remove one of your symptoms, but not the real cause of the problem.
Free to anyone that will cover the shipping cost. Glad to see if goto a good home.
* Massive includes. Every compilation unit ends up including many header files. Most of these header files include more header files, often ones already included. If a header file has previously been included, it must be included a second time as C++ allows the meaning of including a file to differ each inclusion. This results in a vast amount of necessary preprocessing.
* Compiling the same code multiple times. Every compilation unit must generate code for every template it uses, even if other compilation units are generating the same code. Only at link time are the multiple instantiations of the same code collapsed. As the STL is a massive blob of templates this is a frequent issue!