Q: Why GCC is compiling sooo slooowww?
A: That depends on what you mean by "slow". The following table gives "normal" gcc compilation speed, in source lines per second, on a 166-MHz Pentium:
| Source language | Without optimizations | With -O2
|
| C++ | 800 | 400
|
| C | 1800 | 1000
|
Note that the numbers for compilation with -O2 are about 30%
slower for GCC 2.95 and later versions than for previous versions. This
is because GCC now does much more optimizations under -O2 than
previous versions did.
As another data point, compiling the Allegro library takes about 3 minutes on a P500 and about 50 minutes on a 486/DX2-66.
On machines faster or slower than P166, scale these numbers
accordingly. For example, 486/DX2-66 is about 4 times slower than
P166. When comparing to this table, don't forget to count header files
your program #includes in the total line count. And
don't check compilation speed on very short programs (like the
classic Hello, world!), because the overhead of loading the
multiple passes of the compiler will completely hide the compiler
performance. It is also useful to run the compilation twice in
succession, especially if you have a disk cache installed, to prevent
the overhead of the first load from skewing the results.
If your results are close to these (deviations of a few percent are considered "close" here), then that's as fast as you can get with GCC. If they are significantly slower, you may indeed have a problem; read on.
First, check to see if GCC pages to disk when it compiles. This is
manifested by a heavy disk traffic which won't go away even if you have
a large write-back disk cache installed. To be sure, disable the
virtual memory services for your DPMI host (for CWSDPMI, load it
before your program with the -s- switch, or use the
CWSPARAM program to point the swap file to a non-existent drive),
or use CWSDPR0 or PMODE/DJ as the DPMI host, and then
run the compilation again; if the compiler aborts with an error message
saying there isn't enough memory, then it was paging in your
original environment.
If paging does happen, you need to free more extended memory. If you have a RAM disk, make it smaller, or don't use it at all (it only makes compiles run about 20% faster), or make your disk cache smaller (but don't discard the disk cache altogether); if you have other programs which use extended RAM, make them use less of it. Failing all of the above, buy more RAM (see the description of reasonable configuration). Also see recommendations for optimal software configuration.
If GCC doesn't page, check the settings of your disk cache. If you don't
use a cache, install one--this can slash your compilation times by as much
as 40%, more so when compiling a large number of small files. If you
already have a cache, enable its delayed-write (a.k.a. write-back, a.k.a.
staggered-write) operation. Some people disable the delayed-write feature
for safety reasons, to avoid losing files due to system crashes. If you
are worried about this, you can usually gain performance without
sacrificing safety by enabling delayed-write together with an option
that causes the cache to flush the write-behind data before the system
returns to the DOS prompt. (For SmartDrv disk cache, this is
achieved by specifying /N/F switches instead of /X.) GCC
usually gains a lot when you set up your cache in such a way, because
each compiler pass (pre-processor, compiler, assembler) must write
temporary files that are used by the following passes.
It is also worthwhile to check the settings of your system BIOS. In particular, the following items should be checked against your motherboard vendor recommendations:
| Internal and external CPU cache | set to Enable
|
| CPU cache scheme | set to Write-back, if possible
|
| DRAM and SRAM wait states | vendor-recommended optimal values
|
Incorrect or suboptimal settings of the above items can explain as much as 30% performance degradation on 486 machines, and as much as 500% (!) if you have a Pentium CPU.