www.delorie.com/djgpp/v2faq/faq048.html | search |
| Previous | Next | Up | Top |
| Without optimization | With -O2 -----------+------------------------+------------ C++ source | 800 | 400 -----------+------------------------+------------ C source | 1800 | 1000
On machines faster or slower than P166, scale these numbers accordingly. For example, i486/DX2-66 is about 4 times slower than P166. When comparing to this table, don't forget to count header files
your program #include's
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 lower, 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 or 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 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). 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 30%, 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 valuesIncorrect 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.
webmaster donations bookstore | delorie software privacy |
Copyright ⌐ 1998 by Eli Zaretskii | Updated Sep 1998 |
You can help support this site by visiting the advertisers that sponsor it! (only once each, though)