Here is a quick summary of what I've learned the last few years of working with a large code base.
(1) Get the faster possible processor. I would recommend an Intel Core i7 2600K (4 core/8 with HT) or an Intel Core i7 2700K (6 core/12 with HT) as the best price/performance ratio right now. Both of these run at around 3.4Ghz (and can go even faster when only one core is used, such as the case of creating a pre-compiled header.) If your CPU isn’t near the top of this list, you are very likely spending too much time waiting for your compilations: http://www.cpubenchmark.net/high_end_cpus.html
(2) Hyperthreading on Intel processors has made a huge difference on our compile times. It has been a while now, but I believe it was around a 30% speed increase when we started to use HT enabled CPUs.
(3) SSDs make a big difference for C++ builds, about a 50% speedup and it ensures that our CPUs consistently run at 100% utilization. At the moment, we are not finding that SATA 3 drives are that much faster than SATA 2 drivers, maybe because the main benefit we are reaping is due to faster random accesses rather than raw through put. I recommend putting both your Visual C++ install on the SSD as well as your project files because during your compilations all the standard headers that are accessed by your project are actually located where you have installed Visual C++.
(4) Reducing the number of projects is very critical in C++ because of the costs involved in creating pre-compiled headers. (There is a way to create shared pre-compiled headers but we haven't explored that option yet.) I have combined libraries as well as targets. There is a nice trick for combining targets via having the target look at its file name in order to determine its behavior. A friend of mine pointed out that git utilizes this trick as well.
(5) Having a full build solution that builds unchanging dependencies and then switch to a lighter weight project that only builds the projects you are changing (which we do using a smart Cmake-based project file generator) or distributing binaries of unchanging projects can really reduce build times.
(6) Under "Projects and Solutions | Build and Run" there is a "maximum parallel builds" setting. You want to ensure that this is the number of your total HT cores -- so on my machine it is 12 (6 x 2). Also be sure to add to all C++ projects the "/MP" flag that makes the individual builds multithreaded. Yes this will lead to more compilation threads than cores, if you have a couple GB of memory and an SSD, it will lead to the fastest possible build.
(7) Command line builds using MSBuild appear to build slower than builds through Visual Studio.NET. I believe this is because you can't easily do concurrent builds from a single command line (although you can do a multithreaded build via "/MP"), although it may just simply have to do some caching that VS.NET utilizes. But the end result is that outside of automated builds, we do all builds through Visual Studio.NET. This isn’t an exhaustive list of build speed optimizations, but following the rules above has reduced our compiles down to something relatively manageable, and hopefully it can allow you to do the same. Other suggestions on how to reduce our compilation times is appreciated, please send them to email@example.com.