Large projects with dozens of files can take long to compile in visual studio. The build time sometimes run up to 20-30 minutes for a full rebuild. These can be really annoying (or depending on the situation, very convenient ^^ ) especially if you have to do them multiple times per day.
incredibuild. With incredibuild you create a sort of "compile-farm". Computers in your lan get an "incredibuild helper" installed, a small programm which enables this computer to participate in a build started remotely (on a development machine). The incredibuild helper will only help, if the computer is more or less idle (e.g. when the user is using a wordprocessor), and thus helpers will participate in compiling. The developer machines also get an incredibuild helper installed, with special rights to start a remote build. The helper integrates seamlessly into visual studio. With such a setup, we can compile at speeds of 50 Ghz (yes, Gigaherz!) or more. But also incredibuild reaches a limit. We can't add 'unlimited' helper agents, because of the traffic and we slow down the network.
We can also observe that file-access on windows machines slow, and include hierarchies can get very deep (1000+ includes per cpp in a larger projects is no exception!). These have to be parsed each time again for every place they are included, which can take ... forever... However, this also presents an opportunity for optimization. For fun, try including windows.h, then change the file settings (compiler/advance to display the include hierarchy) and compile this .cpp file... you will be amazed how much includes are actually added because of windows.h. So the question remains, how to further reduce compile-times with Visual Studio?
First of all, we could get some issues with static members inside .cpp's - due to the requirement of unique naming. This is solved quickly by renaming them, so that everything is unique.
Now however, we need to make sure the compiler doesn't compile the "seperate" cpp's (or you would get multiple defined symbol linker errors), so with right-click on these files in the solution explorer, we exclude the the single .cpp's from the build.
Now we can compile, each .cpp is only opened once, and "concatenated" into a huge .cpp - which is compiled. There is little file-access, so it's very quick (factor 5-10 quicker is no exception).
I've seen a project compile in 30 minutes (debug only). After using unity builds, combined with incredibuild a rebuild of debug and release was done in less then 6 minutes... A huge gain!
However there are also some disadvantages.
- static variables need to be unique solution-wide
- variables in anonymous namespaces need to be unique solution-wide
- more difficult to fix linker errors (since it will point to the unity file)
- include order might cause issues (especially when using unity for some time and then switching back to normal builds)
- newly added files have to be added to the unity file, and excluded from the build themselves
- building a seperate cpp with ctrl+F7 doesn't work, you have to build the entire project (F7).
From experience I would say these disadvantages aren't so bad. You can even decide to use unity builds only in certain parts of the code, or maybe only in a lowlevel library
I suggest to give it a try!