TITLE: include guards for speeding up compiles (Newsgroups: comp.lang.c++.moderated, 13 Nov 97) FENTON: Ross Fenton > If you only place the guards in include files, then the > compiler still has to parse the full include file looking for > the #endif statements. > > A solution used on my recent projects is to place the guards > in the source file as well, this prevents the file been read > or parsed at all - this should provide an improvement. In our > case it took a 6 hour compile down to 2 hours. I judged this a > success. KANZE: kanze@gabi-soft.fr (J. Kanze) I'd be interested in the exact environment (networking, network load, etc.) -- I've had a similar experience, but it was clear that in that particular case, the network was very much overloaded. (Similarly, link time went from 2 hours to under 20 minutes when we modified the procedure to ensure that the linker ran on the machine where the library files were located.) Sun claims to have made similar measurements, in which the difference for a complete build was only on the order of 10-20% -- not worth the effort. Finally, of course: there should be no need for you to install the guards in the including file. The compiler is fully capable of remembering that the file has been included and is idempotent, and not even open it the second time it sees it. Some compilers do this; if there exists environments where it would make a significant difference (and yours is obviously one), then the compiler really should do this. (In practice, curiously enough, not many do. So you may be stuck with the awkward include guards.) YOUNGMAN: James Youngman The approach I used is very similar; the include guard for foo.h is inside foo.h; #ifndef INC_foo_h #define INC_foo_h #include #endif IMHO this offers the best of both methods; you don't have to modify each of 3,000 source files to get faster compiles, and there is a speedup, just as with Mr. Fenton's example.