views:

3446

answers:

10

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.

+20  A: 

It may sound obvious to you, but we try to use forward declaration 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;
        // ...
    };
}
}

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

Johannes Schaub - litb
You beat me to it =). I try to minimize as much as possible the headers which include other headers by using forward references wherever possible.
Adam Rosenfield
The corollary is to also try to move includes from header files to implementation files when possible.
Boojum
ceretullis
ceretullis, yeah i think that is what he meant. place forward declarations into the header file, and then include header files needed into the implementation file.
Johannes Schaub - litb
@ceretullis: I don't get your point there. If you need some header due to some implementation detail and whatever is defined there (class/funcions) don't take part of your interface you should move that header to the implementation file. Else you will increase coupling and dependencies.
David Rodríguez - dribeas
or do you mean to put forward declarations itself into separate headers like the <iosfwd> standard header? i'm not sure about that, would only make sense to put a limited set of forward declarations then imho.
Johannes Schaub - litb
+5  A: 

We use Xoreax's Incredibuild to run compilation in parallel across multiple machines.

crashmstr
+3  A: 

The compile speed question is interesting enough that Stroustrup has it in his FAQ.

David Norman
+3  A: 

Our development machines are all quad-core and we use Visual Studio 2008 supports parallel compiling. I am uncertain as to whether all editions of VS can do this.

We have a solution file with approximately 168 individual projects, and compile this way takes about 25 minutes on our quad-core machines, compared to about 90 minutes on the single core laptops we give to summer students. Not exactly comparable machines but you get the idea :)

Chris Cameron
It's undocumented but the same flag (/MP) can also be used with VS 2005
Luca Tettamanti
/MP doesn't work well with debug as it is incompatible with incremental builds
Brian R. Bondy
Unfortunately, the link step doesn't seem to be parallel.
David Thornley
+10  A: 

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.

1800 INFORMATION
great suggestion, thanks.
Brian R. Bondy
ceretullis
Using this pattern greatly increases the readability and maintainability of the code, for the reasons I already gave
1800 INFORMATION
+8  A: 

If you have large complex headers that must be included by most of the .cpp files in your build process, and which are not changed very often, you can precompile them. In a Visual C++ project with a typical configuration, this is simply a matter of including them in stdafx.h. This feature has its detractors, but libraries that make full use of templates tend to have a lot of stuff in headers, and precompiled headers are the simplest way to speed up builds in that case.

Daniel Earwicker
+4  A: 

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.

Shmoopty
+2  A: 

With Visual C++, there is a method, some refer to as Unity, that improves link time significantly by reducing the number of object modules. This involves concatenating the c++ code, usually in groups by library. This of course makes editing the code much more difficult and you will run into namespace collisions unless you use them well. Keeps you from using "using namespace foo"; Several teams at our company have elaborate systems to take the normal C++ files and concatenate them at compile time as a build step. The reduction in link times can be enormous.

Matt Shaw
At the cost of compiling time: if you change just one line of your library you will have to compile it completely.
David Rodríguez - dribeas
But it's possible that by concatenating in groups of 2, say, you almost halve the worst-case build time, and increase the best-non-trivial-case build time by only a few percent, because all the compilation time is being spent on code in headers, not code in cpp files. So choose 2 <= n <= everything.
Steve Jessop
+3  A: 

I use Unity Builds (Screencast located here).

OJ
+1  A: 

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

phjr