Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <3B587049.19D267B@codesourcery.com> you write:
>Gerald Pfeifer wrote:

>>                    GCC 2.95                         GCC 3.0
>>           Compile time    Binary size      Compile time   Binary Size
>>   -O0             6:19    3915128                  8:20   4159780
>>   -O1             4:20    4203480                 11:40   4829732
>>   -O2             5:56    4209368                 14:09   4862532
>>   -O3             5:47    4221464                 32:04   6166052

>> This is not (only) an inlining problem it seems?

>From what I understand, the above data is for the build of an entire
program and not just one source translation.  Is that correct, Gerald?

> Do you have the .ii file sizes to compare? Is there a correlation with
> compile time?

[This issue was studied a bit before the 3.0 release, see
 http://gcc.gnu.org/ml/libstdc++/2001-02/msg00365.html and followup.]

Here is some concrete data to answer your questions.  First we study
the speed of header declaration processing.  (BTW, I believe that this
analysis is being quite generous to 3.0 since it deemphasizes the
massive growth in some commonly used standard headers.)

Start with libstdc++-v3/testsuite/17_intro/headers.cc.  Remove all
headers which did not exist in 2.95.  Remove <bitset> since the 2.95
preprocessed source related to that header will not compile under 3.0.
Create 295.ii and 30.ii as follows:

g++-2.95.3 -E headers.cc >295.ii  # 643817 bytes
g++-3.0 -E headers.cc >30.ii  # 1020257 bytes

Run each ii file against each compiler (thus size shouldn't matter):

``g++-2.95.3 -c -O[0-3] 295.ii'' requires about 2.7 seconds on my
platform regardless of optimization level (as expected).  FYI, adding
-fhonor-std or -fnew-abi does not appear to affect speed of
declaration processing.

``g++-3.0 -c -O[0-3] 295.ii'' requires about 4.3 seconds on my
platform regardless of optimization level (as expected).

``g++-2.95.3 -c -O[0-3] 30.ii'' does not compile.  Adding the obvious
extra switches (-fhonor-std -fnew-abi) doesn't help.

``g++-3.0 -c -O[0-3] 30.ii'' requires about 5.7 seconds on my platform
regardless of optimization level (as expected).

The above data was taken from i386-unknown-freebsd4.3.  Here is for
sparc-sun-solaris2.7:

g++-2.95.3 -E headers.cc >295.ii  # 662909 bytes
g++-3.0 -E headers.cc >30.ii  # 1055701 bytes

Times (in same order as above): 4.1s, 7.0s, NA, 9.6s

Times for alpha-unknown-freebsd4.2: 4.2s, 9.1s, NA, 11.7s

I conclude that in terms of header declaration processing, g++ 3.0 is
slower than g++ 2.95.3 by a factor of 1.6 (4.3/2.7) to 2.1 (9.1/4.2).
When one considers that the standard headers are now bigger (much
bigger, in some common cases), it appears slower by a larger factor
when comparing compilation speed of user-provided code.

Next, we would study the code generation processing at various
optimization levels.  Gerald's data displays the issue of code
generation speed for real application code, and I have no better
example to post off-hand.  I am the only one that finds it odd that
-O0 takes longer to compile than -O1, -O2 and -O3 under 2.95.3?

Regards,
Loren