How do YOU reduce compile time, and linking time f

Question

How do YOU reduce compile time, and linking time for VC++ projects (native C++)?

Please specify if each suggestion applies to debug, release, or both.

Answer 1

Use the Handle/Body pattern (also sometimes known as "pimpl", "adapter", "decorator", "bridge" or "wrapper"). By isolating the implementation of your classes into your .cpp files, they need only be compiled once. Most changes do not require changes to the header file so it means you can make fairly extensive changes while only requiring one file to be recompiled. This also encourages refactoring and writing of comments and unit tests since compile time is decreased. Additionally, you automatically separate the concerns of interface and implementation so the interface of your code is simplified.

Answer 2

It may sound obvious to you, but we try to use forward declarations as much as possible, even if it requires to write out long namespace names the type(s) is/are in:

// Forward declaration stuff
namespace plotter { namespace logic { class Plotter; } }

// Real stuff
namespace plotter {
    namespace samples {
        class Window {
            logic::Plotter * mPlotter;
            // ...
        };
    }
}

It greatly reduces the time for compiling also on others compilers. Indeed it applies to all configurations :)

Answer 3

Also an interesting article from Ned Batchelder: http://nedbatchelder.com/blog/200401/speeding_c_links.html (about C++ on Windows).

Answer 4

I use Unity Builds (Screencast located here).

Answer 5

These solutions apply to both debug and release, and are focused on a codebase that is already large and cumbersome.

Forward declarations are a common solution.

Distributed building, such as with Incredibuild is a win.

Pushing code from headers down into source files can work. Small classes, constants, enums and so on might start off in a header file simply because it could have been used in multiple compilation units, but in reality they are only used in one, and could be moved to the cpp file.

A solution I haven't read about but have used is to split large headers. If you have a handful of very large headers, take a look at them. They may contain related information, and may also depend on a lot of other headers. Take the elements that have no dependencies on other files...simple structs, constants, enums and forward declarations and move them from the_world.h to the_world_defs.h. You may now find that a lot of your source files can now include only the_world_defs.h and avoid including all that overhead.

Visual Studio also has a "Show Includes" option that can give you a sense of which source files include many headers and which header files are most frequently included.

For very common includes, consider putting them in a pre-compiled header.

Answer 6

Another useful technique is blobbing. I think it is something similar to what was described by Matt Shaw.

Simply put, you just create one cpp file in which you include other cpp files. You may have two different project configurations, one ordinary and one blob. Of course, blobbing puts some constrains on your code, e.g. class names in unnamed namespaces may clash.

One technique to avoid recompiling the whole code in a blob (as David Rodríguez mentioned) when you change one cpp file - is to have your "working" blob which is created from files modified recently and other ordinary blobs.

We use blobbing at work most of the time, and it reduces project build time, especially link time.