Section A.1. Scaling of Compilers


A.1. Scaling of Compilers

To investigate some of the issues of how a compiler scales, I wrote a small generator program to generate C source code files. This made it easy to vary the number of source files, the number of functions per source file, and the number of included files. Two separate compile scripts were also generated: one that used static libraries (one library per source file) and one that used a single (large) command line with all the object files explicitly named in the command.

The source files that were created were named source_0.c through source_<N>.c, where <N> was the number of files created. Each .c file contained a variable number of functions and looked like the following:

void file_0_fn_0( ) {  } . . . void file_0_fn_9( ) {  }

Source files that were used for testing scaling with the number of included files looked like:

#include "file_0_include_0.h" . . . #include "file_0_include_9.h" void file_0_fn_0( ) {  } . . . void file_0_fn_9( ) {  }

and each header file contained the appropriately numbered copy of this:

#ifndef FILE_0_INCLUDE_0_HDR_GUARD #define FILE_0_INCLUDE_0_HDR_GUARD #define DEFINITION_0_0 "ABC" #endif

A single main.c file contained extern references to all of the defined functions and a call to each function. Durations were measured using the GNU time tool.

A.1.1. How the Compiler gcc Scales

This section describes some simple measurements of the generated projects that were made using a laptop named matt-laptop, with a 300MHz Pentium II CPU and 192MB RAM, lightly loaded, running Red Hat Linux 8.0, and using gcc 3.2.

In summary, as the number of files being compiled increases, the time taken also increases linearly. As the size of the files being compiled increases, and all else is equal, the time taken also increases linearly. Link times also increase linearly as the number of object files or library files being linked together increases. To study how the gcc preprocessor scales by itself, Section A.1.1.4, later in this appendix, shows what happens when the number of #include lines in each source file is increased (each header file was a different file). This change seems to have a smaller effect on the relative compilation times.

The purpose of these figures is to compare how the time taken by a well-known compiler changes with different arguments, not to compare gcc to other compilers.


A.1.1.1. Number of source files

With 10 uniquely named functions per source code file, the time to compile and link a single executable from different numbers of source files is shown in Figure A-1.

Figure A-1. Compiler time versus number of source files


A.1.1.2. Number of functions

For a project with 100 source files, the time was measured for compiling and linking a single executable with a varying number of functions in each source file. The results are shown in Figure A-2.

Figure A-2. Compiler time versus number of functions per source file


A.1.1.3. Number of libraries

For a project with 10 functions per source file, and with one library file per source file, the time to link a single executable is shown in Figure A-3.

Figure A-3. Linker time versus number of library files


A.1.1.4. Number of included files

A project with a large number of included files was generated. Each included file was unique, and all the included files were guarded with unique guard strings, as is common with C header files. For 10 functions per source file and 100 source files, Figure A-4 shows the effect of the number of included files on the overall compiler time. Disk access and whether a file is already cached in memory probably have more effect than processor speed does in this case.

Figure A-4. Compiler time versus number of included files


Most compilers are collections of fairly complicated separate tools such as preprocessors, compilers, and linkers. Each of these applications has its own performance characteristics. So the simple analyses of this section should be taken only as a rough indicator of how a build process will scale. Before deciding on a build tool, it is good practice to generate some large projects that resemble your application and to test the performance of potential build tools with these projects.



Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net