Single Compilation Unit


Single Compilation Unit is a computer programming technique for the C and C++ languages, which reduces compilation time for programs spanning multiple files. Specifically, it allows the compiler to keep data from shared header files, definitions and templates, so that it need not recreate them for each file. It is an instance of program optimization. The technique can be applied to an entire program or to some subset of source files; when applied to an entire program, it is also known as a unity build.

Purpose

In the C/C++ compilation model, individual / source files are preprocessed into translation units, which are then translated separately by the compiler into multiple object files. These object files can then be linked together to create a single executable file or library. However, this leads to multiple passes being performed on common header files, and with C++, multiple template instantiations of the same templates in different translation units.
The Single Compilation Unit technique uses pre-processor directives to "glue" different translation units together at compile time rather than at link time. This reduces the overall build time, due to eliminating the duplication, but increases the incremental build time, due to requiring a full rebuild of the entire unit if any single input file changes. Therefore, this technique is appropriate for a set of infrequently modified source files with significant overlap, or source files that frequently require recompilation together, such as due to all including a common header or template that changes frequently.
Another disadvantage of SCU is that it is serial, compiling all included source files in sequence in one process, and thus cannot be parallelized, as can be done in separate compilation. Thus SCU requires explicit partitioning to parallelize compilation.
SCU also allows an optimizing compiler to perform interprocedural optimization without requiring link-time optimization, therefore allowing optimizations such as inlining, and helps avoiding implicit code bloat due to exceptions, side effects, and register allocation. These optimizations are often not possible in many compilers, due to independent compilation, where optimization happens separately in each translation unit during compilation, but the "dumb linker" simply links object files, without performing any optimizations itself, and thus interprocedural optimization between translation units is not possible.

Example

For example, if you have the source files and, they can be placed in a Single Compilation Unit as follows:

  1. include "foo.cpp"
  2. include "bar.cpp"

Suppose and are:

//foo.cpp
  1. include // A large, standard header
  2. include "bar.h" // Declaration of function 'bar'
int main // Definition of function 'main'


//bar.cpp
  1. include // The same large, standard header
void bar // Definition of function 'bar'


Now the standard header file is compiled only once, and function may be inlined into function, despite being from another module.