I’m not even sure the test was fair because you used two different OSs – shouldn’t you try a win32 build of gcc against MSVC? (maybe you did and I just missed that bit). Could be Win32 file access is just crap or you had a virus checker turned on?

The only real way to test which is better is to take a large existing project and change it over to use #pragma once instead and see what the speed increases are.

Modest use of precompiled headers and internal guards are probably fine though and then you can spend your spare time writing useful code and not worrying about saving a few 10ths of a second compile time

Additionally, I would expect pragma to be faster than the internal guards because the pragma is a first-class function of the pre-processor. When the pre-processor consumes it there is no ambiguity.

Internal guards, on the other hand, are not first-class concepts to pre-processor, they’re constructs built from first-class pre-processor functionality. In other words, the pre-processor doesn’t know that you’re attempting to eliminate redundant header processing. More importantly, the pre-processor has no clue what to do until it has consumed the entire file. And even then, I would doubt the pre-processor (in conjunction with the compiler) is optimized for the specific case of #ifdef’ing a file into emptiness. I would expect the compiler to simply receive an empty file. But, I may not be giving the compiler writers enough credit…

Of course, this may all be stuff that was just being assumed by all of you guys, I am a little “new” to this stuff.

All that being said, I am suprised that Visual Studio trailed so far behind GCC. It doesn’t suprise me it trailed, just by what seemed to be several orders of magnitude for something that didn’t involve any real compiling. Of course, as menteiond before, this test case is particularly pathological. Again, to not disregard the compiler writers, perhaps the Visual Studio approach solves a more common, “real world” problem more efficiently at the expense of this scenario?

Gosh, I sure hope not.

Gosh, I started replying to that, but after I was typing for 10 minutes, I realized it would be best left as a full article. And even though I don’t like to bash products, I really think that Incredibuild can be actually harmful to a project. I’ll put up a full rant tomorrow

Why don’t you like Incredibuild?

The biggest issue we had was that edit and continue is not supported. Other than that it was a massive massive time saver. From 30-40 minute builds down to sub 10 minutes for a complete rebuilt.

It took me about 2 hours or so to get our Unreal based codebase to work with it (with all the compiling and re compiling). But after that start up cost it was smooth sailing.

distcc relies on doing a local preprocessor pass on a file, and then passing it on to the nextwork to be compiled, so I suspect the results would be the same as for the local compilation and #pragma once would work just fine.

It’s true that unknown #pragma directives should be ignored, but that’s not always the case. For example, older versions of gcc used to spew messages saying that #pragma was a deprecated directive. Since #pragmas are totally non-standard, it’s also concievable that compilers can use the same one to mean different things (although highly unlikely with something like #pragma once).

In general, if you plan to compile your code in more than one compiler (a good thing even if you’re only developing for one platform), it’s a good idea to #ifdef the pragma directives so they only apply to the compilers you intended them for.

The holy standard (ISO 14882 – 1998) in section 16.6/1 states:

“A preprocessing directive of the form

#pragma pp-token new-line

causes the implementation to behave in an implementation-defined manner. Any pragma that is not recognized by the implementation is ignored.”