CSBuild

"Chunked" builds

CSBuild, by default, uses build "chunking" - the process of combining multiple translation units into a single one - to improve build time. This has the advantage of both reducing IO and reducing processing time for repeated usage of the same headers. Unlike most chunking systems, however, CSBuild adds an additional step to this - in the course of iteration, chunked builds will slow down iteration on a single file, so CSBuild intelligently creates and splits apart its chunks to try and find the best possible build times in both a full rebuild and an iterative build scenario.

Because chunking of builds can cause some problems, however (redefinition of static symbols, certification problems on certain systems, etc), CSBuild provides functionality to disable chunks both within the makefile and as a command-line switch.

Effective parallel building

CSBuild has a strong focus on effective parallelism, including parallelism between projects, between targets, between platforms - as long as there's something for CSBuild to do, it will make maximum use of the number of threads you give it (which, by default, is the number of CPU cores available to your system). Additionally, CSBuild includes support for parallel linking - but because linking is particularly expensive, it will use only one link thread until its build threads become exhausted, and will only begin spinning up additional link threads at the end of the compilation process.

Better incremental links

The msvc toolchain offers functionality for incremental links, but doesn't allow a link to be performed incrementally if a static library being linked in has changed. By linking in the intermediate .obj files instead of the .lib file, CSBuild is able to take advantage of incremental links, even in situations where a static library change would have normally caused the incremental link to fail. (By default, this is only enabled for debug builds.)

Better change detection

To prevent rebuilding files that have already been built or need no additional work, CSBuild uses MD5 checksums in addition to modification dates to determine whether or not to recompile a translation unit. Since comments don't need to be recompiled, it also strips comments before creating its MD5s; thus, changing only a comment will not cause the object to be rebuilt.

Manual build order adjustments

CSBuild attempts to build things in an appropriate order for the dependency structure set up in the makefile, but sometimes this order isn't the most ideal. For example, sometimes it may take longer for an application to compile than for all of the libraries it depends on to compile and link, resulting in a build that leaves the application compiling and linking by itself long after everything else in the build process is complete. To solve this problem, CSBuild allows you to set project build priorities to move these long builds earlier in the process, so that you spend less time waiting on one long build.

Build analytics

Many of the most effective improvements to build time can be made by the programmer - changing build orders, or changing files themselves to use fewer expensive operations or include fewer expensive headers. To better enable these modifications, CSBuild provides a full suite of build analytics to allow the developer to discover techniques for optimizing builds to improve build time even further.