I am compiling 2 C++ projects in a buildbot, on each commit. Both are around 1000 files, one is 100 kloc, the other 170 kloc. Compilation times are very different from gcc (4.4) to Visual C++ (2008).
Visual C++ compilations for one project take in the 20 minutes. They cannot take advantage of the multiple cores because a project depend on the other. In the end, a full compilation of both projects in Debug and Release, in 32 and 64 bits takes more than 2 1/2 hours.
gcc compilations for one project take in the 4 minutes. It can be parallelized on the 4 cores and takes around 1 min 10 secs. All 8 builds for 4 versions (Debug/Release, 32/64 bits) of the 2 projects are compiled in less than 10 minutes.
What is happening with Visual C++ compilation times? They are basically 5 times slower.
What is the average time that can be expected to compile a C++ kloc? Mine are 7 s/kloc with vc++ and 1.4 s/kloc with gcc.
Can anything be done to speed-up compilation times on Visual C++?
One thing that slows down the VC++ compiler is if you have a header file that initializes concrete instances of non-trival const value types. You may see this happen with constants of type std::string or GUIDs. It affects both compilation and link time.
For a single dll, this caused a 10x slowdown. It helps if you put them in a precompiled header file, or, just declare them in a header and initialize them in a cpp file.
Do take a look into the virus scanner, and be sure to experiment with precompiled headers, without it you won't see VC++ at its best.
Oh yeah, and make sure the %TMP% folder is on the same partition as where your build is written to, as VC++ makes temp files and moves them later.
The projects depending on each other doesn't imply that no parallelization is possible. The build systems are smart enough to figure out and avoid critical depenedancies, Otherwise gcc wouldn't be able to use 4 cores.
So (in addition to other steps), why not just try enabling multiprocessing in Visual Studio using /MP (See http://msdn.microsoft.com/en-us/library/bb385193.aspx).
It's not the direct answer for the question but at my company we are using IncrediBuild for distributed compilation. It really speeds up the compilation process. http://incredibuild.com/visual_studio.htm
How are you building the Visual Studio projects? Are you just running the ide (devenv) with the project and /build or do you have a makefile similar to what I assume you are using for gcc. I'm assuming that both builds use a similar makefile but I thought it worth checking.
Are you using precompiled headers for either compiler? If you're NOT using precompiled headers for VS then you might like to switch to using them. Personally I'd recommend using the #pragma hdrstop approach rather than a single all inclusive header file but if you're currently NOT using precompiled headers and want to try it out a single all inclusive header file that is force included (using the /FI compiler command line switch) can be tested quickly without any code changes.
I wrote about both /FI and #pragma hdrstop here: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html
The book "Large-Scale C++ Software Design" by John Lakos has many tips on structuring your code and design for large-scale projects. Including many tips on speeding up compilation. Not directly related to Visual C++, but well worth reading anyway.
I've written two articles on techniques that reduce the compilation time. Among these techniques a post on precompiled header and unity builds that may help you improve compilation times. They ship with CMake scripts that handle the techniques transparently.
First of all, in most cases you can build debug and release configurations of the same project in parallel.
Also what you describe sounds horribly slow - looks like you don't use precompiled headers in VC++ or using them incorrectly - they are specifically intended to improve compilation time.
Perhaps there is an issue with the dependency checking, unless you are forcing a complete rebuild.
You could make some static libraries. Put code that seldom changes into libraries.
The slowest parts of building a program:
- Opening and closing files.
- Parsing and translating source files.
In general, the linking and executable creation phases are the fastest.
Have you determined:
- which phases are the slowest?
- Which files are slowest to compile?
Remember, when determining efficiency, always profile (in one manner or another).
Are you building on the same machine? Are you using the same OS? I've seen speed differences in the region of 3-10x when comparing GCC in Cygwin and GCC in a VirtualBox machine running inside the Windows hosting Cygwin.
It seems very strange that there would be such a difference... but there is no reason that you cannot take advantage of the multicores on Visual either!
Basically you have 4 compilations modes: (Debug/Release)x(32bits/64bits), each one being totally independent of the other, you could perfectly run the 4 in parallel, taking full advantage of the 4 cores available. Or simply try out the MultiProcessor approach on Visual Studio too.
However that's not going to cut it. 150 minutes versus 10 minutes is a huge gap. From my personal experience there are 2 major factors in reducing compilation time:
- have all files used on a local disk (using replication from remote ones if necessary) and all files created locally too (.o .so)
- use all the cores at your disposal, and if you can, even go Multi Machines (distcc etc...)
Compile and link one cpp file at a time, even when header-file-changes affect multiple cpp files. This can be accomplised with visual studio macro:
Dim WithEvents myTimer As Timers.Timer
Sub CompileAndLinkCurrentCppFile()
DTE.ExecuteCommand("Build.Compile")
myTimer = New Timers.Timer
myTimer.Interval = 0.05
myTimer.Start()
End Sub
Sub myTimer_Elapsed(ByVal ee As Object, ByVal dd As Timers.ElapsedEventArgs) Handles myTimer.Elapsed
If DTE.Solution.SolutionBuild.BuildState <> vsBuildState.vsBuildStateInProgress And DTE.Solution.SolutionBuild.LastBuildInfo <> 1 Then
myTimer.Stop()
DTE.ExecuteCommand("Build.Link")
End If
End Sub
Don't know if this is still an issue and how much improvement you got in the menatime, but if it still stands that msbuild doesn't know how to orchestrate concurrently within one project (each cpp should be separately buildable unless you have some codegens - codegens are best moved to a separate project) you hay have to download driver development kit or .NET SSCLI since they both have nmake, build which are known to paralelize things well. SSCLI already had the build build setup, don't remeber if DDK has some build samples of do you have to start from scratch.
Also a bit oldish article on MSBuild parallelization doesn't go into details but mentiones some diff between actual msbuild and msbuild + sln. If the /MP vs. /Gm was the only issue then you may have to make a little script or C# exe to edit .proj files for lab build. Or use explicit cmd line override in projects and take that option from an env var.
来源：https://stackoverflow.com/questions/2251212/how-to-improve-visual-c-compilation-times