Improve collaborative build times with ccache
By Martin C. Brown2004-11-08
How to squeeze more speed out of your compilations
|
|
Collaboratively building a C/C++ project using cc or gcc to share source files and other components works fine with CVS, but the time required to build the application when it has been merged with everybody else's changes can be significant. Even if you're not developing a project as part of a group, recompiling an application can take a lot of time. The ccache tool improves the build performance by caching the incorporation of header files into source files and therefore speeds the build time by reducing the time required to add in header files with each compilation stage. In this article, learn how to build and install ccache, how to use it with your existing environment, and how to improve the build times in group development projects. You will also see how to use ccache and distcc together to get the best performance out of your development environment.
In the standard build process, developing applications under UNIX with C/C++ generally involves using a compiler such as gcc with some kind of build tool, such as make. The problem with make and just about any C compiler is the way in which the C preprocessor and header files work. If you have a look at a typical C source file, it will incorporate a number of #include references to the various header files.
Each time you compile a file, the C preprocessor (cpp) parses and then includes each of these files and any files that are in turn referenced. By parsing the content, cpp can turn what was a fairly basic 1-KB source file into an 8-KB source file and, in the process, incorporate tens or even hundreds of header files. In a typical development project, a number of header files relevant to the project may be included multiple times in different source files, and each header file may itself reference many others.
During a typical build, the make tool simplifies the process considerably by compiling only the files that have changed since the target was last built. For example, the directory in Listing 1 shows that the foo.o object is older than the last modification time of the corresponding foo.c source file. Meanwhile, bar.o is newer than bar.c. With a suitably configured Makefile, only foo.o would be recompiled from its source.
The problem with make is that it uses the timestamp as the only method of actually determining whether the file needs to be recompiled. Because make also takes header files into the equation, a simple header file change will trigger a later timestamp and therefore a recompilation of the source files. But because of the way CPP works, for example, using the #ifdef statement, these changes may not affect the files that include them. A simple change of modification time can therefore mean that you end up re-compiling source files for no reason. Individually, that time can be significant. Across a team, the effects may be even more pronounced as multiple developers may end up repeating the process many times, maybe even simultaneously over the course of a typical day.
Listing 1. A sample source environment
total 808
-rw------- 1 mc mc 5123 24 Jul 14:17 bar.c
-rw------- 1 mc mc 39474 24 Jul 14:19 bar.o
-rw------- 1 mc mc 7856 24 Jul 14:17 foo.c
-rw------- 1 mc mc 28443 24 Jul 14:19 foo.o
-rwx--x--x 1 mc mc 319742 24 Jul 14:19 foobar*
-rw------- 1 mc mc 1045 24 Jul 14:21 foobar.h
Tutorial Pages:
» How to squeeze more speed out of your compilations
» Using ccache
» Combining ccache and distcc
» Statistics
» Summary
» Resources
First published by IBM DeveloperWorks
|
| Related Tutorials: » How to Install PHP 5 on Linux » How to Install Apache 2 on Linux » How to Install MySQL 5.0 on Linux » SMB Caching » Mound --Bind » Tar Wild Card Interpretation |