www.delorie.com/djgpp/faq/performance/gcc-slow.html   search  
Why is compiling so SLOW?

Why gcc is compiling sooo slooowww?

That depends on what you mean by slow. The following table gives normal gcc compilation speed, in source lines per second, on a 486DX2-66:

           |  Without optimization  |  With -O2
-----------+------------------------+------------
C++ source |        150             |   100
-----------+------------------------+------------
C   source |        350             |   250

(Btw, these numbers are about 20% faster than you will get on a 40MHz Sparc2 box.) On machines faster or slower than 486DX2-66, scale these numbers appropriately. When comparing to this table, don't forget to count header files your program #include's in the total line count.

If your results are close to these (deviations of few percents are considered ``close'' here), then that's as fast as you can get with gcc. If they are significantly lower, you may indeed have a problem; read on.

First, check to see if gcc pages to disk when it compiles. To this end, put topline into your GO32 environment variable and look at the used physical RAM numbers. Compare this to what go32 reports as available memory when run with no arguments. Do you seem to use all the available physical RAM? If so, 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 to run about 10% 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 in chapter 2 of this FAQ). See also the recommendations for optimal software configuration.

If gcc doesn't come close to the amount of free extended RAM, check settings of your disk cache. If you don't use a cache, install one--this can slash your compilation times by as much as 20%, more so when compiling a large number of small files. If you already have a cache, enable its delayed-write (aka write-back, aka staggered-write) operation.

If you have himem installed and/or use noems parameter to your memory manager, you should stubedit gcc and change the "Maximum amount of virtual memory to keep when spawning" from 1024K to 0.

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:

Incorrect or suboptimal settings of the above items can explain as much as 30% performance degradation.

A well-tuned 90 MHz Pentium system with 32 MBytes of RAM and 4 MBytes of RAM disk can compile the entire gcc source in about 20 minutes.

For very large (several MBytes) executables which are built from a large number of small source files, the link stage might be the one which needs more RAM than you have free. Check that the size of the executable isn't larger than the amount of free RAM reported by go32. If it is, then it might make sense to use a smaller (or even no) disk cache, and allow the linker as much physical RAM as it needs.


  webmaster     delorie software   privacy  
  Copyright © 1995     Updated Feb 1995