There are 3 stages at C++ compilation process which cannot be ignored:
1) preprocessing
2) compilation
3) linking

1) Number of includes and type of includes matters here. This stage simply needs to touch all files, maybe at least once for each compilation unit. Number of such includes can be in *tens of thousands*.Depending on file system and total number of individual files, as well as any other file system operations, it may take disproportionate amount of time. In my experience, majority of projects suffer from this stage. Two common techniques for improvement are PIMPL and forward declarations.

2) Once preprocessor is done, the file to be built is one single, typically multi-megabyte .cpp file. It's fed to compiler, which generates a single .obj/.o file, containing raw symbols and their definitions. To test how long stage 1 and stage 2 take, look under switches to generate pre-processed file. Compare the time it takes to pre-process vs. time to compile this file. ccache or commercial products (e.g. Incredibuild) can help with this stage.

3) With faster disks and more RAM, as well as concurrent compilation, linking is increasingly becoming a bottleneck, being inherently serial. After testing previous two stages, measure the link time. About the only option that reduces this is unity build. Instead of building building each compilation unit independently, there is one .cpp, which includes all other .cpp (!) files. To build a project, one builds only and only this "unity" file. Downside is complete rebuild - partial rebuilds are no longer possible.


C++ build process knowledge is integral part of developing of C++, the sooner you learn and understand it, the better. There are rarely any silver bullets here, process involves way too many variables.

>> Hope you can share if you have experience on Intel C++ compil

Yes, I've used the Intel compiler on several projects.

It *can* be slow depending on what compiler options you feed it.

The default compiler options spend quite a lot of effort on optimization. Often the individual gains are very tiny; that is where the Intel compiler's value resides.

Some options, such as whole-program optimization, will search the entire app looking for anything that ought to be inlined; looks for constants in one section of code that can be applied in another section of code to reduce or eliminate instructions, etc. Another big place the Intel compiler shines (and is slow) is looking for vectorization. That is, it looks for places it can convert loops into parallel loops with SIMD. Turning on profile guided optimizations based on actual use patterns (provided by QA or by actual customer data) is another great performance improvement with a very high optimization cost.

There are many similar things it can do that are compute-intensive. The optimizer is extremely good, and if you are building a high-performance application where compute time is measured in hours or days (such as weather forecasting, or geological volumetric processing) then those few extra hours in compiling can save many compute-days of time in the final build released by the company; profile-guided optimization in that case can give incredible performance boosts. In cases where the software is run for a long time on supercomputers, it can save many compute-weeks just in a single run of the app.


It is great for automated overnight final builds that go to QA and eventually get shipped.

It is wonderful for the optimization reports it generates that explains ways to get better peformance.

It is much less great at getting highly-optimized results quickly.

I'd recommend against using the compiler for your developer builds unless you turn off many of the optimizations.

But does it explain why Intel C++ Compiler is so slower than GCC and VC?

....

I've encountered that slowness when building C++ projects comes from one or more stages in build process. Maybe I should write an overview on what exactly contributes to each stage and how to diagnose it...

Yup, that knowledge is quite valuable. But does it explain why Intel C++ Compiler is so slower than GCC and VC?

I've pointed out a general direction in which you could look, there is no useful answer without knowing anything more.

For comparison, boost takes ~15 minutes to build for me and there's some pretty gnarly pre-processor and template code in there. So the project you're talking about is fairly large, if GCC takes about that time.

Virtual machines tend to have poor IO performance (see #1 point). So the most trivial cause of slowdown would be different IO patterns during #1, which can result in n^2 file access in worst-case vs. n. Could. I don't know if this the case for your particual project.


What about comparison of GCC vs. Intel with no optimizations? Is it still slower?

I googled and didn't find much information. Very few forum discussions said it's slow.[/quote]

What if it's not? Hence I suggested 3 points to look at to provide more insight into the particual project you're dealing with.