Re: Suggestions for improving gcc 3.2 compilation speed?

Re: Suggestions for improving gcc 3.2 compilation speed?

[Benjamin Kosnik]

> I have a g++ compiler that is 5.6x faster than the current g++ when
> compiling large C++ code bases. That's when compared to a g++ PCH,
> without it, more like 8x to 16x faster when PCH isn't used.

Your PCH numbers are interesting to me.

I cannot get PCH to work with g++. How are you able to do this? Are you
generating individual .pch files for each header (don't see any
significant speed improvement), or are you using -include
big_globbed_header.h.pch (and if so, can you port the patches to do this
to mainline g++, because it currently doesn't work), or is there another
approach?

See this thread, and follow-ups.
http://gcc.gnu.org/ml/libstdc++/2003-03/msg00025.html

curious, 
benjamin

Re: Suggestions for improving gcc 3.2 compilation speed?

[Karel Gardas]

On Fri, 7 Mar 2003, Benjamin Kosnik wrote:

> > I have a g++ compiler that is 5.6x faster than the current g++ when
> > compiling large C++ code bases. That's when compared to a g++ PCH,
> > without it, more like 8x to 16x faster when PCH isn't used.
>
> Your PCH numbers are interesting to me.
>
> I cannot get PCH to work with g++. How are you able to do this? Are you
> generating individual .pch files for each header (don't see any
> significant speed improvement), or are you using -include
> big_globbed_header.h.pch (and if so, can you port the patches to do this
> to mainline g++, because it currently doesn't work), or is there another
> approach?
>

I'm also interested since I still see while using PCH (at least on 2 weeks
old main-trunk sources) already defined symbol assembler error messages.
Problem reported: http://gcc.gnu.org/ml/gcc/2003-01/msg00419.html

Thanks,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: Suggestions for improving gcc 3.2 compilation speed?

[Geoff Keating]

Karel Gardas <kgardas@objectsecurity.com> writes:

> On Fri, 7 Mar 2003, Benjamin Kosnik wrote:
> 
> > > I have a g++ compiler that is 5.6x faster than the current g++ when
> > > compiling large C++ code bases. That's when compared to a g++ PCH,
> > > without it, more like 8x to 16x faster when PCH isn't used.
> >
> > Your PCH numbers are interesting to me.
> >
> > I cannot get PCH to work with g++. How are you able to do this? Are you
> > generating individual .pch files for each header (don't see any
> > significant speed improvement), or are you using -include
> > big_globbed_header.h.pch (and if so, can you port the patches to do this
> > to mainline g++, because it currently doesn't work), or is there another
> > approach?
> >
> 
> I'm also interested since I still see while using PCH (at least on 2 weeks
> old main-trunk sources) already defined symbol assembler error messages.
> Problem reported: http://gcc.gnu.org/ml/gcc/2003-01/msg00419.html

Darwin uses stabs at the moment, so Mike won't see the DWARF problems
you're seeing.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Suggestions for improving gcc 3.2 compilation speed?

[Mike Stump]

On Friday, March 7, 2003, at 11:12 AM, Benjamin Kosnik wrote:
>> I have a g++ compiler that is 5.6x faster than the current g++ when
>> compiling large C++ code bases. That's when compared to a g++ PCH,
>> without it, more like 8x to 16x faster when PCH isn't used.
>
> Your PCH numbers are interesting to me.
>
> I cannot get PCH to work with g++. How are you able to do this? Are you
> generating individual .pch files for each header (don't see any
> significant speed improvement), or are you using -include
> big_globbed_header.h.pch (and if so, can you port the patches to do 
> this
> to mainline g++, because it currently doesn't work), or is there 
> another
> approach?

We use -include.  We generate one large application .gch file that 
include tons of things in it.

bash-2.05a$ wc MillenniumFE.ii
   152201  333117 4298858 MillenniumFE.ii

That is the .ii file of the file that is -included.  This generates a 
30-40 MB .gch file.  The application has 279 translation units in it.

I don't know offhand why it works for us and not you.  Random guess, I 
thought I saw something about TAKES_ARG go by recently in another 
context...  Found it, in cppspec.c Devang added 
DEFFAULT_WORD_TAKES_ARG, is this related to why -include doesn't work?

The best win I can think of for g++ would be to create all, and include 
all the headers one can, and change all headers to inlcude all, and 
then precompile all, and link it around under all the various names 
that can be used and fix the can't do more than abs names problem in 
PCH.

This doesn't rely upon -include, works out of the box for all the std 
include files, maximal win, easy to use, just #include one of the 
normal C++ headers before anything else in the .cc files.

Re: Suggestions for improving gcc 3.2 compilation speed?

[Devang Patel]

On Friday, March 7, 2003, at 03:24 PM, Mike Stump wrote:

> I don't know offhand why it works for us and not you.  Random guess, I 
> thought I saw something about TAKES_ARG go by recently in another 
> context...  Found it, in cppspec.c Devang added 
> DEFFAULT_WORD_TAKES_ARG, is this related to why -include doesn't work?

-include does not work with g++. (PR 9394). I have the fix. I will post 
patch when bootstrap and regression test is complete.

-Devang

Re: Suggestions for improving gcc 3.2 compilation speed?

[Benjamin Kosnik]

>I don't know offhand why it works for us and not you.  Random guess, I 
>thought I saw something about TAKES_ARG go by recently in another 
>context...  Found it, in cppspec.c Devang added 
>DEFFAULT_WORD_TAKES_ARG, is this related to why -include doesn't work?

c++/9394 c++ -include doesn't work

says:

Copy the DEFAULT_WORD_SWITCH_TAKES_ARG from gcc.c into gcc/cp/g++spec.c
and use it instead.

-benjamin

Re: Suggestions for improving gcc 3.2 compilation speed?

[Geoff Keating]

Mike Stump <mrs@apple.com> writes:

> On Friday, March 7, 2003, at 11:12 AM, Benjamin Kosnik wrote:
> >> I have a g++ compiler that is 5.6x faster than the current g++ when
> >> compiling large C++ code bases. That's when compared to a g++ PCH,
> >> without it, more like 8x to 16x faster when PCH isn't used.
> >
> > Your PCH numbers are interesting to me.
> >
> > I cannot get PCH to work with g++. How are you able to do this? Are you
> > generating individual .pch files for each header (don't see any
> > significant speed improvement), or are you using -include
> > big_globbed_header.h.pch (and if so, can you port the patches to do
> > this
> > to mainline g++, because it currently doesn't work), or is there
> > another
> > approach?
> 
> We use -include.  We generate one large application .gch file that
> include tons of things in it.
> 
> bash-2.05a$ wc MillenniumFE.ii
>    152201  333117 4298858 MillenniumFE.ii
> 
> That is the .ii file of the file that is -included.  This generates a
> 30-40 MB .gch file.  The application has 279 translation units in it.
> 
> I don't know offhand why it works for us and not you.  Random guess, I
> thought I saw something about TAKES_ARG go by recently in another
> context...  Found it, in cppspec.c Devang added
> DEFFAULT_WORD_TAKES_ARG, is this related to why -include doesn't work?

It could be that problem; we don't hit it because the prefix headers
in much of our source aren't named like *.h and the problem only
occurs if you do '-include xxx.h'.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Suggestions for improving gcc 3.2 compilation speed?

[Benjamin Kosnik]

>The best win I can think of for g++ would be to create all, and include 
>all the headers one can, and change all headers to inlcude all, and 
>then precompile all, and link it around under all the various names 
>that can be used and fix the can't do more than abs names problem in 
>PCH.
>
>This doesn't rely upon -include, works out of the box for all the std 
>include files, maximal win, easy to use, just #include one of the 
>normal C++ headers before anything else in the .cc files.

Well....

With Devang's patch I can do this, only I used std++.h.pch as "include
all." I'm not quite sure what you mean by the "link it around under all the
various names that can be used and fix the..." bits.

However, still.

baseline cvs, no pch
1031.380u 68.120s 23:47.94 76.9%        0+0k 0+0io 1687168pf+0w

cvs with stamp-std-precompile,  C++ includes as individual pch files
1005.580u 67.070s 23:43.49 75.3%        0+0k 0+0io 1678954pf+0w

-include stdc++.h, stdc++.h.pch generated
1563.800u 103.100s 34:36.41 80.2%       0+0k 0+0io 1784752pf+0w

#include stdc++.h, stdc++.h.pch generated
1017.940u 66.770s 24:34.06 73.5%        0+0k 0+0io 1684457pf+0w

When I run the compiler with "-v -H" I get

#include "..." search starts here:
#include <...> search starts here:
 /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include
 /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
 /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/backward
 /mnt/hd/src/gcc/libstdc++-v3/libsupc++
 /mnt/hd/src/gcc/libstdc++-v3/testsuite
 /mnt/hd/bld/gcc/gcc/include
 /usr/local/include
 /mnt/hd/bld/H-x86-gcc/include
 /usr/include
End of search list.
GNU C++ version 3.4 20030308 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.4 20030308 (experimental).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64154

. /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/string
.. /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h
.. /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/c++config.h

etc, etc, etc. Tell me if I'm doing something wrong, but I thought this
was how it was supposed to work...

This is with

<bkoz@belmont> /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include
%ll stdc++.h.pch
-rw-rw-r--    1 bkoz     bkoz          13M Mar  8 01:43 stdc++.h.pch


Where stdc++.h includes all the C++ standard includes.

Is the .pch just not being used?

-benjamin

Re: Suggestions for improving gcc 3.2 compilation speed?

[Geoff Keating]

Benjamin Kosnik <bkoz@redhat.com> writes:

> >The best win I can think of for g++ would be to create all, and include 
> >all the headers one can, and change all headers to inlcude all, and 
> >then precompile all, and link it around under all the various names 
> >that can be used and fix the can't do more than abs names problem in 
> >PCH.
> >
> >This doesn't rely upon -include, works out of the box for all the std 
> >include files, maximal win, easy to use, just #include one of the 
> >normal C++ headers before anything else in the .cc files.
> 
> Well....
> 
> With Devang's patch I can do this, only I used std++.h.pch as "include
> all." I'm not quite sure what you mean by the "link it around under all the
> various names that can be used and fix the..." bits.
> 
> However, still.
> 
> baseline cvs, no pch
> 1031.380u 68.120s 23:47.94 76.9%        0+0k 0+0io 1687168pf+0w
> 
> cvs with stamp-std-precompile,  C++ includes as individual pch files
> 1005.580u 67.070s 23:43.49 75.3%        0+0k 0+0io 1678954pf+0w
> 
> -include stdc++.h, stdc++.h.pch generated
> 1563.800u 103.100s 34:36.41 80.2%       0+0k 0+0io 1784752pf+0w
> 
> #include stdc++.h, stdc++.h.pch generated
> 1017.940u 66.770s 24:34.06 73.5%        0+0k 0+0io 1684457pf+0w
> 
> When I run the compiler with "-v -H" I get
> 
> #include "..." search starts here:
> #include <...> search starts here:
>  /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include
>  /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
>  /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/backward
>  /mnt/hd/src/gcc/libstdc++-v3/libsupc++
>  /mnt/hd/src/gcc/libstdc++-v3/testsuite
>  /mnt/hd/bld/gcc/gcc/include
>  /usr/local/include
>  /mnt/hd/bld/H-x86-gcc/include
>  /usr/include
> End of search list.
> GNU C++ version 3.4 20030308 (experimental) (i686-pc-linux-gnu)
>         compiled by GNU C version 3.4 20030308 (experimental).
> GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64154
> 
> . /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/string
> .. /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h
> .. /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/c++config.h
> 
> etc, etc, etc. Tell me if I'm doing something wrong, but I thought this
> was how it was supposed to work...
> 
> This is with
> 
> <bkoz@belmont> /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include
> %ll stdc++.h.pch
> -rw-rw-r--    1 bkoz     bkoz          13M Mar  8 01:43 stdc++.h.pch
> 
> 
> Where stdc++.h includes all the C++ standard includes.
> 
> Is the .pch just not being used?

It's possible.  

You might want to check whether you're using a compiler that uses .pch
or .gch as the PCH extension.

Also, consider using the -Winvalid-pch flag.
-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Suggestions for improving gcc 3.2 compilation speed?

[Benjamin Kosnik]

>> Is the .pch just not being used?
>
>It's possible. 

I'm hoping that it's not being used, just from the timings.

I was hoping for a bit more info than this if possible. Like, should the
.pch file show up in -v -H? How is this debugged?

>You might want to check whether you're using a compiler that uses .pch
>or .gch as the PCH extension.

Apparently, mainline g++ on linux uses .pch by default. I tried to just
generate a pch as you've previously instructed and the output file has
.pch, not .gch. 

Perhaps you could try this yourself?

>Also, consider using the -Winvalid-pch flag.

Ummmm, yeah. Done and done. 

On mainline gcc, you can generate a precompiled C++ include for
libstdc++-v3 with relatively small effort. To recap:

cd bld/target/libstdc++-v3/include
make stamp-std-precompile

Also, at the suggestion of Mike Stump, I re-did the C++ includes to
first include stdc++.h. Then, I generated a stdc++.h.pch. That approach,
which is only a stylistic variation, can be found here:

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00694.html

I'm not quite sure what to do now.

-benjamin

Re: Suggestions for improving gcc 3.2 compilation speed?

[Geoff Keating]

> Date: Sat, 8 Mar 2003 15:12:57 -0600
> From: Benjamin Kosnik <bkoz@redhat.com>
> Cc: gcc@gcc.gnu.org

> >> Is the .pch just not being used?
> >
> >It's possible. 
> 
> I'm hoping that it's not being used, just from the timings.
> 
> I was hoping for a bit more info than this if possible. Like, should the
> .pch file show up in -v -H? How is this debugged?

It doesn't seem to show up in -H, not sure why (or what the correct
behaviour might be).  I usually debug using -MD.

> >You might want to check whether you're using a compiler that uses .pch
> >or .gch as the PCH extension.
> 
> Apparently, mainline g++ on linux uses .pch by default. I tried to just
> generate a pch as you've previously instructed and the output file has
> .pch, not .gch. 

Aargh.  That's a bug.  It creates with .pch, but is looking for .gch.
I'm testing the one-character fix now.

> Perhaps you could try this yourself?

I will.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Suggestions for improving gcc 3.2 compilation speed?

[Benjamin Kosnik]

>It doesn't seem to show up in -H, not sure why (or what the correct
>behaviour might be).  I usually debug using -MD.

Hmmm. 

It looks to me like -MD and -H output is identical. 

In terms of default behavior, I'd hope for the following:

- no .gch file is generated if it is incorrect (The present behavior,
where a flawed .gch file is emitted still baffles me)

- -H to show that the precompiled header file is being used. Perhaps
something like:

insert.o: 21_strings/insert.cc \
  /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/string \
  /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h \
  (using) /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h.pch \
...

The current behavior, on both of these points, is kind of confusing.

>Aargh.  That's a bug.  It creates with .pch, but is looking for .gch.
>I'm testing the one-character fix now.
>
>> Perhaps you could try this yourself?
>
>I will.

I've tried mainline after your patch (thanks) and still see don't see
any improvement. Perhaps it's something else?

-benjamin

Re: Suggestions for improving gcc 3.2 compilation speed?

[Mike Stump]

On Saturday, March 8, 2003, at 12:20 AM, Benjamin Kosnik wrote:
> I'm not quite sure what you mean by the "link it around under all the
> various names that can be used and fix the..." bits.

old .h contents:

map:
[ contents of map ]

list:
[ contents of list ]

new scheme:

map:
#include <all>
list:
#include <all>

all:
#include <old_map>
#include <old_list>

old_map:
[ contents of map ]

old_list:
[ contnets of list ]

and then precompile all, then ln all.gch map.gch; ln all.gch list.gch.  
Total disk space, sizeof(all) + just a little overhead * number of 
files in the C++ standard.  Benefit can be made to kick in for any 
source files that are like:

#include <all>
[ ... ]

or
#include <map>

or
#include <list>

and the benefits extend through to all standard C++ headers, for 
example:

#include <list>
#include "myproject"
#include <map>

has cost of mmap (all) + groking (myproject), that's it.  Currently, it 
has cost groking (list) + groking (myproject) + groking (map).

> However, still.
>
> baseline cvs, no pch
> 1031.380u 68.120s 23:47.94 76.9%        0+0k 0+0io 1687168pf+0w
>
> cvs with stamp-std-precompile,  C++ includes as individual pch files
> 1005.580u 67.070s 23:43.49 75.3%        0+0k 0+0io 1678954pf+0w
>
> -include stdc++.h, stdc++.h.pch generated
> 1563.800u 103.100s 34:36.41 80.2%       0+0k 0+0io 1784752pf+0w

I suspect this isn't using PCH!  Only absolute names work currently?!

try -include `pwd`/stdc++.h or whatever the dir is.

> #include stdc++.h, stdc++.h.pch generated
> 1017.940u 66.770s 24:34.06 73.5%        0+0k 0+0io 1684457pf+0w

This looks better?  Not sure, as it is only 1-2 seconds faster than the 
first.

I think -v should say if a pch file is used, otherwise, it is hard to 
tell when the mechanism kicks in, well, unless you have a huge .h file 
and you know exactly how long it takes to parse, and mmap.  Wanna put a 
fprintf (stderr, "PCH file %s being used\n", name); in cpp_read_state?  
I think that will make it easy for the user to understand when PCH is 
used, and more importantly, to spot when it isn't being used.

pch messages [was: Re: Suggestions for improving gcc 3.2 compilation speed?]

[Karel Gardas]

On Mon, 10 Mar 2003, Mike Stump wrote:

> I think -v should say if a pch file is used, otherwise, it is hard to
> tell when the mechanism kicks in, well, unless you have a huge .h file
> and you know exactly how long it takes to parse, and mmap.  Wanna put a
> fprintf (stderr, "PCH file %s being used\n", name); in cpp_read_state?
> I think that will make it easy for the user to understand when PCH is
> used, and more importantly, to spot when it isn't being used.

JFYI: como prints such info too. E.g.

como  -I../include --pch --pch_dir /home/karel/arch/sl3/sl3/./pch
-DFAST_PCH -g  -a --long_long --implicit_extern_c_type_conversion
--diag_suppress=997     -c poa_base.cc -o poa_base.o

"poa_base.cc": using precompiled header file "/home/karel/arch/sl3/sl3/./pch/current.pch"
como  -I../include --pch --pch_dir /home/karel/arch/sl3/sl3/./pch
-DFAST_PCH -g  -a --long_long --implicit_extern_c_type_conversion
--diag_suppress=997     -c poa_impl.cc -o poa_impl.o

"poa_impl.cc": using precompiled header file "/home/karel/arch/sl3/sl3/./pch/os-unix.pch"
como  -I../include --pch --pch_dir /home/karel/arch/sl3/sl3/./pch
-DFAST_PCH -g  -a --long_long --implicit_extern_c_type_conversion
--diag_suppress=997     -c dynany.cc -o dynany.o

"dynany.cc": using precompiled header file "/home/karel/arch/sl3/sl3/./pch/current.pch"


Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: pch messages [was: Re: Suggestions for improving gcc 3.2 compilation speed?]

[B. Kosnik]

>"poa_impl.cc": using precompiled header file "/home/karel/arch/sl3/sl3/./pch/os-unix.pch"

I'd like something like this too!

>  Wanna put a 
>fprintf (stderr, "PCH file %s being used\n", name); in cpp_read_state?  
>I think that will make it easy for the user to understand when PCH is 
>used, and more importantly, to spot when it isn't being used.

Yes, but I think precompiled file is better than PCH. Do you think this
is the right place for it?

-benjamin

Re: pch messages [was: Re: Suggestions for improving gcc 3.2 compilation speed?]

[Mike Stump]

On Monday, March 10, 2003, at 04:40 PM, B. Kosnik wrote:
> Yes, but I think precompiled file is better than PCH.

Agreed.

> Do you think this is the right place for it?

I don't see that it is terribly wrong.  Geoff may have a better 
suggestion.

Re: pch messages [was: Re: Suggestions for improving gcc 3.2 compilation speed?]

[Geoff Keating]

Mike Stump <mrs@apple.com> writes:

> On Monday, March 10, 2003, at 04:40 PM, B. Kosnik wrote:
> > Yes, but I think precompiled file is better than PCH.
> 
> Agreed.
> 
> > Do you think this is the right place for it?
> 
> I don't see that it is terribly wrong.  Geoff may have a better
> suggestion.

Someone (maybe even bkoz) suggested that -H should provide this
information; that certainly sounds like the right place to have
debugging info for header-inclusion problems.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: pch messages

[Zack Weinberg]

Geoff Keating <geoffk@geoffk.org> writes:

> Someone (maybe even bkoz) suggested that -H should provide this
> information; that certainly sounds like the right place to have
> debugging info for header-inclusion problems.

Agree.  Patches are welcome.  (If we do this, we should make -H more
prominently documented.)

zw

Re: Suggestions for improving gcc 3.2 compilation speed?

[Michael Matz]

Hi,

On Fri, 14 Mar 2003, Zack Weinberg wrote:

> 'Recursive Make Considered Harmful', Peter Miller.  Abstract, and link
> to full text, at
> <http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html>.

<shameless plug>
Use unsermake (KDE CVS, kdenonbeta/unsermake).  Its input files resemble
automake Makefile.am's (so it's not that difficult to "port"  existing
projects to it), but it creates a Makefile hierarchy including the whole
tree (including inter-directory dependencies) which is then processed by
one make from the toplevel.  A parallel make on this tree is _much_ faster
than with automake (because it's parallelism is limited to one directory).
For KDE with a compile server in the back it's extremely usefull.
</shameless plug>

It has some issues with sub-directory configures, but is Good Enough (TM)
for us ;-)


Ciao,
Michael.

Re: Suggestions for improving gcc 3.2 compilation speed?

[Kaveh R. Ghazi]

 > From: Zack Weinberg <zack@codesourcery.com>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > > It gets much worse if you have split this into
 > > subdirectories, then cd into directories and run another copy of make.
 > > Someone (Zack?) once posted an article which explained why this is
 > > very bad and changed gcc to avoid doing this.  I wish I could find it.
 > 
 > 'Recursive Make Considered Harmful', Peter Miller.  Abstract, and link
 > to full text, at
 > <http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html>.
 > zw

That's the one.  Thanks Zack.

<click-save>

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Suggestions for improving gcc 3.2 compilation speed?

[Zack Weinberg]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> It gets much worse if you have split this into
> subdirectories, then cd into directories and run another copy of make.
> Someone (Zack?) once posted an article which explained why this is
> very bad and changed gcc to avoid doing this.  I wish I could find it.

'Recursive Make Considered Harmful', Peter Miller.  Abstract, and link
to full text, at
<http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html>.

zw

Re: Suggestions for improving gcc 3.2 compilation speed?

[Kaveh R. Ghazi]

 > From: Anna Fowles-Winkler <awinkler@maad.com>
 > 
 > Ooops... I forgot to show the difference.  A full compile of my 
 > application means that 593 *.C files are compiled (and there are about 
 > 300 header files, not including standard ones from C/C++ or X).

Thanks for the info.  It sounds like you have a lot of files.  There
can be a significant overhead in simply having `make' check all the
dependencies, stat'ing files, etc, so it knows what to compile.  This
is especially true if every file depends on many (most? all?) of the
300 header files.  It gets much worse if you have split this into
subdirectories, then cd into directories and run another copy of make.
Someone (Zack?) once posted an article which explained why this is
very bad and changed gcc to avoid doing this.  I wish I could find it.

Anyway, if the files you listed are representative (as opposed to the
best ones) then the improvement is even better than I originally
thought.  The average "before" time is (2.88+3.83+2.98)/3 == 3.23 and
the average "after" time is (2.12+2.75+2.44)/3 == 2.44.  Dividing
3.23/2.44 we get a ratio of 1.323, i.e. better than when including
overall `make' time.

Thanks for all your testing!  Good luck with your app, I hope you find
GCC useful and fast enough for your needs.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Suggestions for improving gcc 3.2 compilation speed?

[Anna Fowles-Winkler]

Kaveh R. Ghazi wrote:

> > From: Anna Fowles-Winkler <awinkler@maad.com>
> > 
> > Hi Kaveh,
> > 
> > Kaveh R. Ghazi wrote:
> > 
> > > > --Anna
> > > > PS - My application is mixed C/C++, and is compiled with the C++ 
> > > > compiler.  It has about 300K lines of code (400K+ including comments, 
> > > > blank lines), and links to Motif libraries, among other things.
> > >
> > >Would you please try one more thing?  I'd like you to take your
> > >largest file (or the one that takes the longest to compile) and run
> > >before and after tests with --time-report, then post the results.
> > >That will tell us where the compiler is spending it's time and also
> > >zero in on gcc performance rather than "make" performance.
> > >
> > >		Thanks,
> > >		--Kaveh
> > >
> > I'm doing a full compile when I do this, so I picked out the longest 
> > execution times for a few files to include here:
>
>Hmm Can't see anything unusual about where time is going.  These look
>like all small files, i.e. 3-8 seconds to compile isn't a lot.  I
>assume you have lots of small files rather than a few large ones?
>By the way, which are "before" times and which are "after" the patch?
>
Ooops... I forgot to show the difference.  A full compile of my 
application means that 593 *.C files are compiled (and there are about 
300 header files, not including standard ones from C/C++ or X).

Here are some times for a few files, all compiled with gcc 3.2.2.  I've 
noted the times with and without the patch that you sent.

dbObjectDB.C
------------

without patch:
Execution times (seconds)
 garbage collection    :   0.47 (22%) usr   0.02 ( 7%) sys   0.59 (21%) wall
 cfg cleanup           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.20 ( 9%) usr   0.06 (20%) sys   0.31 (11%) wall
 lexical analysis      :   0.13 ( 6%) usr   0.13 (43%) sys   0.20 ( 7%) wall
 parser                :   0.93 (44%) usr   0.05 (17%) sys   1.05 (36%) wall
 expand                :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 varconst              :   0.08 ( 4%) usr   0.02 ( 7%) sys   0.16 ( 5%) wall
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 local alloc           :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 global alloc          :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 final                 :   0.02 ( 1%) usr   0.01 ( 3%) sys   0.02 ( 1%) wall
 symout                :   0.20 ( 9%) usr   0.01 ( 3%) sys   0.42 (15%) wall
 rest of compilation   :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 TOTAL                 :   2.12             0.30             2.88

with patch:
Execution times (seconds)
 cfg construction      :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 life analysis         :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.18 (11%) usr   0.08 (26%) sys   0.25 (12%) wall
 lexical analysis      :   0.22 (13%) usr   0.12 (39%) sys   0.38 (18%) wall
 parser                :   0.84 (52%) usr   0.10 (32%) sys   1.12 (53%) wall
 expand                :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 varconst              :   0.08 ( 5%) usr   0.00 ( 0%) sys   0.09 ( 4%) wall
 local alloc           :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 reg stack             :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 final                 :   0.03 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 symout                :   0.23 (14%) usr   0.00 ( 0%) sys   0.16 ( 7%) wall
 TOTAL                 :   1.63             0.31             2.12

taskNewtorkModelDB.C
--------------------

without patch:
Execution times (seconds)
 garbage collection    :   0.56 (20%) usr   0.00 ( 0%) sys   0.73 (19%) wall
 cfg construction      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 life analysis         :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 life info update      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.23 ( 8%) usr   0.07 (19%) sys   0.31 ( 8%) wall
 lexical analysis      :   0.17 ( 6%) usr   0.11 (30%) sys   0.41 (11%) wall
 parser                :   1.10 (39%) usr   0.17 (46%) sys   1.56 (41%) wall
 expand                :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 varconst              :   0.09 ( 3%) usr   0.01 ( 3%) sys   0.08 ( 2%) wall
 integration           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 jump                  :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 local alloc           :   0.04 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
 global alloc          :   0.15 ( 5%) usr   0.00 ( 0%) sys   0.19 ( 5%) wall
 shorten branches      :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
 reg stack             :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 final                 :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 symout                :   0.24 ( 9%) usr   0.01 ( 3%) sys   0.30 ( 8%) wall
 rest of compilation   :   0.07 ( 2%) usr   0.00 ( 0%) sys   0.06 ( 2%) wall
 TOTAL                 :   2.82             0.37             3.83

with patch:
Execution times (seconds)
 cfg construction      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 2%) wall
 life analysis         :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 life info update      :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 preprocessing         :   0.21 ( 9%) usr   0.13 (38%) sys   0.34 (12%) wall
 lexical analysis      :   0.12 ( 5%) usr   0.05 (15%) sys   0.28 (10%) wall
 parser                :   1.20 (54%) usr   0.12 (35%) sys   1.31 (48%) wall
 expand                :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 varconst              :   0.06 ( 3%) usr   0.01 ( 3%) sys   0.06 ( 2%) wall
 jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 mode switching        :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 local alloc           :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.06 ( 2%) wall
 global alloc          :   0.08 ( 4%) usr   0.01 ( 3%) sys   0.03 ( 1%) wall
 flow 2                :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 shorten branches      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 reg stack             :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 final                 :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 symout                :   0.23 (10%) usr   0.01 ( 3%) sys   0.19 ( 7%) wall
 rest of compilation   :   0.09 ( 4%) usr   0.01 ( 3%) sys   0.16 ( 6%) wall
 TOTAL                 :   2.23             0.34             2.75

task DB.C
---------

without patch:
Execution times (seconds)
 garbage collection    :   0.46 (19%) usr   0.00 ( 0%) sys   0.50 (17%) wall
 cfg construction      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 cfg cleanup           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 life analysis         :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.11 ( 4%) wall
 life info update      :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.16 ( 7%) usr   0.09 (33%) sys   0.17 ( 6%) wall
 lexical analysis      :   0.16 ( 7%) usr   0.08 (30%) sys   0.27 ( 9%) wall
 parser                :   0.94 (38%) usr   0.08 (30%) sys   1.16 (39%) wall
 expand                :   0.08 ( 3%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 varconst              :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 integration           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 local alloc           :   0.06 ( 2%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 global alloc          :   0.17 ( 7%) usr   0.00 ( 0%) sys   0.19 ( 6%) wall
 shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 final                 :   0.09 ( 4%) usr   0.01 ( 4%) sys   0.06 ( 2%) wall
 symout                :   0.14 ( 6%) usr   0.01 ( 4%) sys   0.17 ( 6%) wall
 rest of compilation   :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 TOTAL                 :   2.46             0.27             2.98

with patch:
Execution times (seconds)
 cfg construction      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 cfg cleanup           :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 life analysis         :   0.03 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 life info update      :   0.01 ( 1%) usr   0.01 ( 3%) sys   0.03 ( 1%) wall
 preprocessing         :   0.12 ( 6%) usr   0.06 (18%) sys   0.19 ( 8%) wall
 lexical analysis      :   0.18 ( 9%) usr   0.11 (32%) sys   0.19 ( 8%) wall
 parser                :   0.91 (48%) usr   0.11 (32%) sys   1.12 (46%) wall
 expand                :   0.06 ( 3%) usr   0.02 ( 6%) sys   0.09 ( 4%) wall
 varconst              :   0.05 ( 3%) usr   0.01 ( 3%) sys   0.09 ( 4%) wall
 integration           :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 jump                  :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 flow analysis         :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 mode switching        :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 local alloc           :   0.08 ( 4%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 global alloc          :   0.11 ( 6%) usr   0.00 ( 0%) sys   0.16 ( 6%) wall
 flow 2                :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 shorten branches      :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 reg stack             :   0.01 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 final                 :   0.07 ( 4%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 symout                :   0.16 ( 8%) usr   0.02 ( 6%) sys   0.31 (13%) wall
 rest of compilation   :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.06 ( 3%) wall
 TOTAL                 :   1.91             0.34             2.44

Thanks!
Anna

Re: Suggestions for improving gcc 3.2 compilation speed?

[Anna Fowles-Winkler]

Garen wrote:

>>Out of curiousity, I compiled my application with Intel's c++ compiler, and 
>>it took 11 minutes. (Again, 2.8 Ghz, 1 GB RAM).
>>
>>Also, I'm not compiling with any optimizations with either g++ or Intel's 
>>compiler.
>>    
>>
> 
>Just to check, are you sure you explicitly disabled optimizations with -O0 
>with icc?  Because it enables -O2 by default if you don't.
>
> 
>  
>
Oh... no I wasn't specifically including -O0.... so if it is enabling 
-O2 by default then the compile is taking longer than it would with the 
-O0 (right?).  That still isn't too bad that Intel's compiler took 11 
minutes with -O2 optimizations.

--Anna

Re: Suggestions for improving gcc 3.2 compilation speed?

[Mike Stump]

On Friday, March 7, 2003, at 12:40 PM, Karel Gardas wrote:
> I'm interested in testing it, but unfortunatelly it doesn't apply 
> cleanly
> (I suppose you are talking about main-trunk):

It needs more development than testing.

> Against which version exactly is this patch?

Apple's copy of the 3.3 tree as of Feb 15th or so.

Re: Suggestions for improving gcc 3.2 compilation speed?

[Geoff Keating]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

>  > From: Anna Fowles-Winkler <awinkler@maad.com>
>  > 
>  > Hi Kaveh,
>  > 
>  > Kaveh R. Ghazi wrote:
>  > 
>  > > > --Anna
>  > > > PS - My application is mixed C/C++, and is compiled with the C++ 
>  > > > compiler.  It has about 300K lines of code (400K+ including comments, 
>  > > > blank lines), and links to Motif libraries, among other things.
>  > >
>  > >Would you please try one more thing?  I'd like you to take your
>  > >largest file (or the one that takes the longest to compile) and run
>  > >before and after tests with --time-report, then post the results.
>  > >That will tell us where the compiler is spending it's time and also
>  > >zero in on gcc performance rather than "make" performance.
>  > >
>  > >		Thanks,
>  > >		--Kaveh
>  > >
>  > I'm doing a full compile when I do this, so I picked out the longest 
>  > execution times for a few files to include here:
> 
> Hmm Can't see anything unusual about where time is going.  These look
> like all small files, i.e. 3-8 seconds to compile isn't a lot.  I
> assume you have lots of small files rather than a few large ones?
> By the way, which are "before" times and which are "after" the patch?

This looks very much like Apple's Finder_FE timing testcase.
Basically, all the time is spent in preprocessing and parsing header
files, with the occasional file that actually has significant code in
it and so exercises the code generation.  For example:

>  Execution times (seconds)
>   preprocessing         :   0.16 ( 7%) usr   0.04 (11%) sys   0.30 (11%) wall
>   lexical analysis      :   0.11 ( 5%) usr   0.14 (37%) sys   0.36 (13%) wall
>   parser                :   1.11 (52%) usr   0.17 (45%) sys   1.20 (45%) wall
>   symout                :   0.23 (11%) usr   0.01 ( 3%) sys   0.25 ( 9%) wall
       subtotal                     75%              96%              78%
>   TOTAL                 :   2.14             0.38             2.69

This is exactly the kind of thing that PCH is supposed to help with.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Suggestions for improving gcc 3.2 compilation speed?

[Kaveh R. Ghazi]

 > From: Anna Fowles-Winkler <awinkler@maad.com>
 > 
 > Hi Kaveh,
 > 
 > Kaveh R. Ghazi wrote:
 > 
 > > > --Anna
 > > > PS - My application is mixed C/C++, and is compiled with the C++ 
 > > > compiler.  It has about 300K lines of code (400K+ including comments, 
 > > > blank lines), and links to Motif libraries, among other things.
 > >
 > >Would you please try one more thing?  I'd like you to take your
 > >largest file (or the one that takes the longest to compile) and run
 > >before and after tests with --time-report, then post the results.
 > >That will tell us where the compiler is spending it's time and also
 > >zero in on gcc performance rather than "make" performance.
 > >
 > >		Thanks,
 > >		--Kaveh
 > >
 > I'm doing a full compile when I do this, so I picked out the longest 
 > execution times for a few files to include here:

Hmm Can't see anything unusual about where time is going.  These look
like all small files, i.e. 3-8 seconds to compile isn't a lot.  I
assume you have lots of small files rather than a few large ones?
By the way, which are "before" times and which are "after" the patch?


 > Execution times (seconds)
 >  cfg cleanup           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  life analysis         :   0.04 ( 2%) usr   0.01 ( 3%) sys   0.03 ( 1%) wall
 >  life info update      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  preprocessing         :   0.23 (10%) usr   0.09 (26%) sys   0.33 (11%) wall
 >  lexical analysis      :   0.15 ( 7%) usr   0.10 (29%) sys   0.48 (16%) wall
 >  parser                :   1.32 (58%) usr   0.13 (38%) sys   1.53 (52%) wall
 >  expand                :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  varconst              :   0.09 ( 4%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 >  integration           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  local alloc           :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  global alloc          :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  shorten branches      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  final                 :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  symout                :   0.23 (10%) usr   0.00 ( 0%) sys   0.28 (10%) wall
 >  rest of compilation   :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  TOTAL                 :   2.27             0.34             2.94
 > 
 > Execution times (seconds)
 >  life analysis         :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  preprocessing         :   0.30 (13%) usr   0.11 (25%) sys   0.27 ( 9%) wall
 >  lexical analysis      :   0.26 (11%) usr   0.11 (25%) sys   0.38 (12%) wall
 >  parser                :   1.32 (56%) usr   0.19 (43%) sys   1.86 (61%) wall
 >  expand                :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  varconst              :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.12 ( 4%) wall
 >  integration           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  jump                  :   0.00 ( 0%) usr   0.01 ( 2%) sys   0.00 ( 0%) wall
 >  mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  local alloc           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  global alloc          :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  final                 :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  symout                :   0.30 (13%) usr   0.02 ( 5%) sys   0.30 (10%) wall
 >  rest of compilation   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  TOTAL                 :   2.37             0.44             3.03
 > 
 > Execution times (seconds)
 >  cfg construction      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  cfg cleanup           :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  life analysis         :   0.11 ( 5%) usr   0.01 ( 4%) sys   0.14 ( 6%) wall
 >  life info update      :   0.02 ( 1%) usr   0.01 ( 4%) sys   0.03 ( 1%) wall
 >  preprocessing         :   0.12 ( 6%) usr   0.06 (21%) sys   0.22 ( 9%) wall
 >  lexical analysis      :   0.09 ( 4%) usr   0.07 (25%) sys   0.05 ( 2%) wall
 >  parser                :   0.71 (34%) usr   0.10 (36%) sys   1.02 (40%) wall
 >  expand                :   0.09 ( 4%) usr   0.01 ( 4%) sys   0.17 ( 7%) wall
 >  varconst              :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  integration           :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  jump                  :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  flow analysis         :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  mode switching        :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 >  local alloc           :   0.12 ( 6%) usr   0.00 ( 0%) sys   0.11 ( 4%) wall
 >  global alloc          :   0.22 (11%) usr   0.00 ( 0%) sys   0.23 ( 9%) wall
 >  flow 2                :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  shorten branches      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  reg stack             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  final                 :   0.13 ( 6%) usr   0.01 ( 4%) sys   0.08 ( 3%) wall
 >  symout                :   0.09 ( 4%) usr   0.01 ( 4%) sys   0.09 ( 4%) wall
 >  rest of compilation   :   0.10 ( 5%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 >  TOTAL                 :   2.06             0.28             2.53
 > 
 > Execution times (seconds)
 >  cfg construction      :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.14 ( 2%) wall
 >  cfg cleanup           :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.11 ( 1%) wall
 >  life analysis         :   0.42 ( 6%) usr   0.05 ( 8%) sys   0.47 ( 6%) wall
 >  life info update      :   0.15 ( 2%) usr   0.02 ( 3%) sys   0.17 ( 2%) wall
 >  preprocessing         :   0.31 ( 4%) usr   0.08 (13%) sys   0.36 ( 4%) wall
 >  lexical analysis      :   0.21 ( 3%) usr   0.16 (25%) sys   0.48 ( 6%) wall
 >  parser                :   2.05 (30%) usr   0.19 (30%) sys   2.25 (28%) wall
 >  expand                :   0.59 ( 9%) usr   0.02 ( 3%) sys   0.56 ( 7%) wall
 >  varconst              :   0.10 ( 1%) usr   0.01 ( 2%) sys   0.12 ( 2%) wall
 >  integration           :   0.05 ( 1%) usr   0.00 ( 0%) sys   0.08 ( 1%) wall
 >  jump                  :   0.08 ( 1%) usr   0.01 ( 2%) sys   0.08 ( 1%) wall
 >  flow analysis         :   0.06 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
 >  mode switching        :   0.20 ( 3%) usr   0.00 ( 0%) sys   0.16 ( 2%) wall
 >  local alloc           :   0.44 ( 6%) usr   0.01 ( 2%) sys   0.52 ( 6%) wall
 >  global alloc          :   0.95 (14%) usr   0.02 ( 3%) sys   1.05 (13%) wall
 >  flow 2                :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
 >  shorten branches      :   0.08 ( 1%) usr   0.00 ( 0%) sys   0.20 ( 3%) wall
 >  reg stack             :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
 >  final                 :   0.33 ( 5%) usr   0.05 ( 8%) sys   0.52 ( 6%) wall
 >  symout                :   0.34 ( 5%) usr   0.01 ( 2%) sys   0.30 ( 4%) wall
 >  rest of compilation   :   0.31 ( 4%) usr   0.00 ( 0%) sys   0.30 ( 4%) wall
 >  TOTAL                 :   6.89             0.63             8.00
 > 
 > Execution times (seconds)
 >  cfg construction      :   0.23 ( 3%) usr   0.02 ( 4%) sys   0.28 ( 3%) wall
 >  cfg cleanup           :   0.84 (12%) usr   0.00 ( 0%) sys   0.95 (12%) wall
 >  life analysis         :   0.50 ( 7%) usr   0.07 (12%) sys   0.52 ( 6%) wall
 >  life info update      :   0.16 ( 2%) usr   0.02 ( 4%) sys   0.23 ( 3%) wall
 >  preprocessing         :   0.26 ( 4%) usr   0.05 ( 9%) sys   0.36 ( 4%) wall
 >  lexical analysis      :   0.17 ( 2%) usr   0.15 (27%) sys   0.41 ( 5%) wall
 >  parser                :   1.48 (21%) usr   0.19 (34%) sys   1.70 (21%) wall
 >  expand                :   0.46 ( 6%) usr   0.00 ( 0%) sys   0.44 ( 5%) wall
 >  varconst              :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 1%) wall
 >  integration           :   0.05 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 1%) wall
 >  jump                  :   0.13 ( 2%) usr   0.01 ( 2%) sys   0.08 ( 1%) wall
 >  flow analysis         :   0.05 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 1%) wall
 >  mode switching        :   0.15 ( 2%) usr   0.00 ( 0%) sys   0.17 ( 2%) wall
 >  local alloc           :   0.49 ( 7%) usr   0.01 ( 2%) sys   0.45 ( 6%) wall
 >  global alloc          :   0.96 (13%) usr   0.01 ( 2%) sys   1.08 (13%) wall
 >  shorten branches      :   0.10 ( 1%) usr   0.00 ( 0%) sys   0.12 ( 2%) wall
 >  reg stack             :   0.14 ( 2%) usr   0.00 ( 0%) sys   0.22 ( 3%) wall
 >  final                 :   0.35 ( 5%) usr   0.01 ( 2%) sys   0.33 ( 4%) wall
 >  symout                :   0.21 ( 3%) usr   0.00 ( 0%) sys   0.22 ( 3%) wall
 >  rest of compilation   :   0.37 ( 5%) usr   0.02 ( 4%) sys   0.42 ( 5%) wall
 >  TOTAL                 :   7.19             0.56             8.14
 > 
 > Execution times (seconds)
 >  cfg construction      :   0.00 ( 0%) usr   0.01 ( 3%) sys   0.05 ( 2%) wall
 >  life analysis         :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  life info update      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  preprocessing         :   0.16 ( 7%) usr   0.04 (11%) sys   0.30 (11%) wall
 >  lexical analysis      :   0.11 ( 5%) usr   0.14 (37%) sys   0.36 (13%) wall
 >  parser                :   1.11 (52%) usr   0.17 (45%) sys   1.20 (45%) wall
 >  expand                :   0.10 ( 5%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  varconst              :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 >  jump                  :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  local alloc           :   0.03 ( 1%) usr   0.01 ( 3%) sys   0.03 ( 1%) wall
 >  global alloc          :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 >  shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  reg stack             :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  final                 :   0.08 ( 4%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 >  symout                :   0.23 (11%) usr   0.01 ( 3%) sys   0.25 ( 9%) wall
 >  rest of compilation   :   0.09 ( 4%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 >  TOTAL                 :   2.14             0.38             2.69
 > 
 > Execution times (seconds)
 >  cfg construction      :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  life analysis         :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  preprocessing         :   0.21 (10%) usr   0.06 (16%) sys   0.38 (14%) wall
 >  lexical analysis      :   0.11 ( 5%) usr   0.12 (32%) sys   0.30 (11%) wall
 >  parser                :   1.28 (60%) usr   0.17 (45%) sys   1.39 (52%) wall
 >  expand                :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  varconst              :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 >  jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  mode switching        :   0.01 ( 0%) usr   0.01 ( 3%) sys   0.00 ( 0%) wall
 >  local alloc           :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  global alloc          :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  flow 2                :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  reg stack             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  final                 :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  symout                :   0.26 (12%) usr   0.02 ( 5%) sys   0.31 (12%) wall
 >  rest of compilation   :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  TOTAL                 :   2.14             0.38             2.66
 > 
 > Execution times (seconds)
 >  cfg construction      :   0.01 ( 0%) usr   0.01 ( 3%) sys   0.00 ( 0%) wall
 >  cfg cleanup           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  life analysis         :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  life info update      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  preprocessing         :   0.15 ( 7%) usr   0.11 (30%) sys   0.34 (12%) wall
 >  lexical analysis      :   0.17 ( 7%) usr   0.11 (30%) sys   0.34 (12%) wall
 >  parser                :   1.27 (56%) usr   0.11 (30%) sys   1.34 (47%) wall
 >  expand                :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  varconst              :   0.13 ( 6%) usr   0.00 ( 0%) sys   0.12 ( 4%) wall
 >  jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  flow analysis         :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  local alloc           :   0.02 ( 1%) usr   0.01 ( 3%) sys   0.02 ( 1%) wall
 >  global alloc          :   0.09 ( 4%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 >  flow 2                :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  reg stack             :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  final                 :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.06 ( 2%) wall
 >  symout                :   0.23 (10%) usr   0.02 ( 5%) sys   0.33 (12%) wall
 >  rest of compilation   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  TOTAL                 :   2.28             0.37             2.84
 > 
 > Execution times (seconds)
 >  life analysis         :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  life info update      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 >  preprocessing         :   0.21 ( 9%) usr   0.03 ( 9%) sys   0.23 ( 8%) wall
 >  lexical analysis      :   0.19 ( 8%) usr   0.12 (36%) sys   0.36 (12%) wall
 >  parser                :   1.18 (52%) usr   0.17 (52%) sys   1.58 (52%) wall
 >  expand                :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 >  varconst              :   0.08 ( 4%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 >  jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  mode switching        :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  local alloc           :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.06 ( 2%) wall
 >  global alloc          :   0.08 ( 4%) usr   0.00 ( 0%) sys   0.11 ( 4%) wall
 >  shorten branches      :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  reg stack             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 >  final                 :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 >  symout                :   0.24 (11%) usr   0.00 ( 0%) sys   0.25 ( 8%) wall
 >  rest of compilation   :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.16 ( 5%) wall
 >  TOTAL                 :   2.26             0.33             3.05
 > 
 > Also, I compile with these options:
 > 
 > g++ -g -pedantic -Wall
 > 
 > Thanks again!
 > Anna

Re: Suggestions for improving gcc 3.2 compilation speed?

[Anna Fowles-Winkler]

Hi Kaveh,

Kaveh R. Ghazi wrote:

> > From: Anna Fowles-Winkler <awinkler@maad.com>
> > 
> > Hi Kaveh,
> > 
> > I ran gcc 3.2.2 with the patch, and it took 15 minutes instead of 18 
> > minutes to compile my application.  That's a slight improvement,
>
>Looks like around 20% improvement.  I wouldn't call that "slight".
>It's pretty hard to get that much better out of gcc, especially with a
>two line patch. :-)
>  
>
True!

> > but I 
> > guess my ideal running time would be closer to 10 minutes.  Am I 
> > dreaming? :)
>
>I don't know, how long does your code take to compile with 2.95.3 or
>some other compiler?
>
>
> > I think at this point I'm either going to go back to 2.95.3, or consider 
> > a commercial compiler.
> > 
> > Thanks to everyone for your support.
> > --Anna
> > 
> > PS - My application is mixed C/C++, and is compiled with the C++ 
> > compiler.  It has about 300K lines of code (400K+ including comments, 
> > blank lines), and links to Motif libraries, among other things.
>
>Would you please try one more thing?  I'd like you to take your
>largest file (or the one that takes the longest to compile) and run
>before and after tests with --time-report, then post the results.
>That will tell us where the compiler is spending it's time and also
>zero in on gcc performance rather than "make" performance.
>
>		Thanks,
>		--Kaveh
>
I'm doing a full compile when I do this, so I picked out the longest 
execution times for a few files to include here:

Execution times (seconds)
 cfg cleanup           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 life analysis         :   0.04 ( 2%) usr   0.01 ( 3%) sys   0.03 ( 1%) wall
 life info update      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.23 (10%) usr   0.09 (26%) sys   0.33 (11%) wall
 lexical analysis      :   0.15 ( 7%) usr   0.10 (29%) sys   0.48 (16%) wall
 parser                :   1.32 (58%) usr   0.13 (38%) sys   1.53 (52%) wall
 expand                :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 varconst              :   0.09 ( 4%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 integration           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 local alloc           :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 global alloc          :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 shorten branches      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 final                 :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 symout                :   0.23 (10%) usr   0.00 ( 0%) sys   0.28 (10%) wall
 rest of compilation   :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 TOTAL                 :   2.27             0.34             2.94

Execution times (seconds)
 life analysis         :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.30 (13%) usr   0.11 (25%) sys   0.27 ( 9%) wall
 lexical analysis      :   0.26 (11%) usr   0.11 (25%) sys   0.38 (12%) wall
 parser                :   1.32 (56%) usr   0.19 (43%) sys   1.86 (61%) wall
 expand                :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 varconst              :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.12 ( 4%) wall
 integration           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 jump                  :   0.00 ( 0%) usr   0.01 ( 2%) sys   0.00 ( 0%) wall
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 local alloc           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 global alloc          :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 final                 :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 symout                :   0.30 (13%) usr   0.02 ( 5%) sys   0.30 (10%) wall
 rest of compilation   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 TOTAL                 :   2.37             0.44             3.03

Execution times (seconds)
 cfg construction      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 cfg cleanup           :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 life analysis         :   0.11 ( 5%) usr   0.01 ( 4%) sys   0.14 ( 6%) wall
 life info update      :   0.02 ( 1%) usr   0.01 ( 4%) sys   0.03 ( 1%) wall
 preprocessing         :   0.12 ( 6%) usr   0.06 (21%) sys   0.22 ( 9%) wall
 lexical analysis      :   0.09 ( 4%) usr   0.07 (25%) sys   0.05 ( 2%) wall
 parser                :   0.71 (34%) usr   0.10 (36%) sys   1.02 (40%) wall
 expand                :   0.09 ( 4%) usr   0.01 ( 4%) sys   0.17 ( 7%) wall
 varconst              :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 integration           :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 jump                  :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 flow analysis         :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 mode switching        :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 local alloc           :   0.12 ( 6%) usr   0.00 ( 0%) sys   0.11 ( 4%) wall
 global alloc          :   0.22 (11%) usr   0.00 ( 0%) sys   0.23 ( 9%) wall
 flow 2                :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 shorten branches      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 reg stack             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 final                 :   0.13 ( 6%) usr   0.01 ( 4%) sys   0.08 ( 3%) wall
 symout                :   0.09 ( 4%) usr   0.01 ( 4%) sys   0.09 ( 4%) wall
 rest of compilation   :   0.10 ( 5%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 TOTAL                 :   2.06             0.28             2.53

Execution times (seconds)
 cfg construction      :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.14 ( 2%) wall
 cfg cleanup           :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.11 ( 1%) wall
 life analysis         :   0.42 ( 6%) usr   0.05 ( 8%) sys   0.47 ( 6%) wall
 life info update      :   0.15 ( 2%) usr   0.02 ( 3%) sys   0.17 ( 2%) wall
 preprocessing         :   0.31 ( 4%) usr   0.08 (13%) sys   0.36 ( 4%) wall
 lexical analysis      :   0.21 ( 3%) usr   0.16 (25%) sys   0.48 ( 6%) wall
 parser                :   2.05 (30%) usr   0.19 (30%) sys   2.25 (28%) wall
 expand                :   0.59 ( 9%) usr   0.02 ( 3%) sys   0.56 ( 7%) wall
 varconst              :   0.10 ( 1%) usr   0.01 ( 2%) sys   0.12 ( 2%) wall
 integration           :   0.05 ( 1%) usr   0.00 ( 0%) sys   0.08 ( 1%) wall
 jump                  :   0.08 ( 1%) usr   0.01 ( 2%) sys   0.08 ( 1%) wall
 flow analysis         :   0.06 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
 mode switching        :   0.20 ( 3%) usr   0.00 ( 0%) sys   0.16 ( 2%) wall
 local alloc           :   0.44 ( 6%) usr   0.01 ( 2%) sys   0.52 ( 6%) wall
 global alloc          :   0.95 (14%) usr   0.02 ( 3%) sys   1.05 (13%) wall
 flow 2                :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
 shorten branches      :   0.08 ( 1%) usr   0.00 ( 0%) sys   0.20 ( 3%) wall
 reg stack             :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
 final                 :   0.33 ( 5%) usr   0.05 ( 8%) sys   0.52 ( 6%) wall
 symout                :   0.34 ( 5%) usr   0.01 ( 2%) sys   0.30 ( 4%) wall
 rest of compilation   :   0.31 ( 4%) usr   0.00 ( 0%) sys   0.30 ( 4%) wall
 TOTAL                 :   6.89             0.63             8.00

Execution times (seconds)
 cfg construction      :   0.23 ( 3%) usr   0.02 ( 4%) sys   0.28 ( 3%) wall
 cfg cleanup           :   0.84 (12%) usr   0.00 ( 0%) sys   0.95 (12%) wall
 life analysis         :   0.50 ( 7%) usr   0.07 (12%) sys   0.52 ( 6%) wall
 life info update      :   0.16 ( 2%) usr   0.02 ( 4%) sys   0.23 ( 3%) wall
 preprocessing         :   0.26 ( 4%) usr   0.05 ( 9%) sys   0.36 ( 4%) wall
 lexical analysis      :   0.17 ( 2%) usr   0.15 (27%) sys   0.41 ( 5%) wall
 parser                :   1.48 (21%) usr   0.19 (34%) sys   1.70 (21%) wall
 expand                :   0.46 ( 6%) usr   0.00 ( 0%) sys   0.44 ( 5%) wall
 varconst              :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 1%) wall
 integration           :   0.05 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 1%) wall
 jump                  :   0.13 ( 2%) usr   0.01 ( 2%) sys   0.08 ( 1%) wall
 flow analysis         :   0.05 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 1%) wall
 mode switching        :   0.15 ( 2%) usr   0.00 ( 0%) sys   0.17 ( 2%) wall
 local alloc           :   0.49 ( 7%) usr   0.01 ( 2%) sys   0.45 ( 6%) wall
 global alloc          :   0.96 (13%) usr   0.01 ( 2%) sys   1.08 (13%) wall
 shorten branches      :   0.10 ( 1%) usr   0.00 ( 0%) sys   0.12 ( 2%) wall
 reg stack             :   0.14 ( 2%) usr   0.00 ( 0%) sys   0.22 ( 3%) wall
 final                 :   0.35 ( 5%) usr   0.01 ( 2%) sys   0.33 ( 4%) wall
 symout                :   0.21 ( 3%) usr   0.00 ( 0%) sys   0.22 ( 3%) wall
 rest of compilation   :   0.37 ( 5%) usr   0.02 ( 4%) sys   0.42 ( 5%) wall
 TOTAL                 :   7.19             0.56             8.14

Execution times (seconds)
 cfg construction      :   0.00 ( 0%) usr   0.01 ( 3%) sys   0.05 ( 2%) wall
 life analysis         :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 life info update      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 preprocessing         :   0.16 ( 7%) usr   0.04 (11%) sys   0.30 (11%) wall
 lexical analysis      :   0.11 ( 5%) usr   0.14 (37%) sys   0.36 (13%) wall
 parser                :   1.11 (52%) usr   0.17 (45%) sys   1.20 (45%) wall
 expand                :   0.10 ( 5%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 varconst              :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 jump                  :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 local alloc           :   0.03 ( 1%) usr   0.01 ( 3%) sys   0.03 ( 1%) wall
 global alloc          :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 reg stack             :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 final                 :   0.08 ( 4%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 symout                :   0.23 (11%) usr   0.01 ( 3%) sys   0.25 ( 9%) wall
 rest of compilation   :   0.09 ( 4%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 TOTAL                 :   2.14             0.38             2.69

Execution times (seconds)
 cfg construction      :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 life analysis         :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 preprocessing         :   0.21 (10%) usr   0.06 (16%) sys   0.38 (14%) wall
 lexical analysis      :   0.11 ( 5%) usr   0.12 (32%) sys   0.30 (11%) wall
 parser                :   1.28 (60%) usr   0.17 (45%) sys   1.39 (52%) wall
 expand                :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 varconst              :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 mode switching        :   0.01 ( 0%) usr   0.01 ( 3%) sys   0.00 ( 0%) wall
 local alloc           :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 global alloc          :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 flow 2                :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 reg stack             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 final                 :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 symout                :   0.26 (12%) usr   0.02 ( 5%) sys   0.31 (12%) wall
 rest of compilation   :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 TOTAL                 :   2.14             0.38             2.66

Execution times (seconds)
 cfg construction      :   0.01 ( 0%) usr   0.01 ( 3%) sys   0.00 ( 0%) wall
 cfg cleanup           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 life analysis         :   0.05 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 life info update      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 preprocessing         :   0.15 ( 7%) usr   0.11 (30%) sys   0.34 (12%) wall
 lexical analysis      :   0.17 ( 7%) usr   0.11 (30%) sys   0.34 (12%) wall
 parser                :   1.27 (56%) usr   0.11 (30%) sys   1.34 (47%) wall
 expand                :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 varconst              :   0.13 ( 6%) usr   0.00 ( 0%) sys   0.12 ( 4%) wall
 jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 flow analysis         :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 local alloc           :   0.02 ( 1%) usr   0.01 ( 3%) sys   0.02 ( 1%) wall
 global alloc          :   0.09 ( 4%) usr   0.00 ( 0%) sys   0.08 ( 3%) wall
 flow 2                :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 reg stack             :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 final                 :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.06 ( 2%) wall
 symout                :   0.23 (10%) usr   0.02 ( 5%) sys   0.33 (12%) wall
 rest of compilation   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 TOTAL                 :   2.28             0.37             2.84

Execution times (seconds)
 life analysis         :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 life info update      :   0.02 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.21 ( 9%) usr   0.03 ( 9%) sys   0.23 ( 8%) wall
 lexical analysis      :   0.19 ( 8%) usr   0.12 (36%) sys   0.36 (12%) wall
 parser                :   1.18 (52%) usr   0.17 (52%) sys   1.58 (52%) wall
 expand                :   0.06 ( 3%) usr   0.00 ( 0%) sys   0.09 ( 3%) wall
 varconst              :   0.08 ( 4%) usr   0.00 ( 0%) sys   0.05 ( 2%) wall
 jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 mode switching        :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 local alloc           :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.06 ( 2%) wall
 global alloc          :   0.08 ( 4%) usr   0.00 ( 0%) sys   0.11 ( 4%) wall
 shorten branches      :   0.03 ( 1%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 reg stack             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 1%) wall
 final                 :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.03 ( 1%) wall
 symout                :   0.24 (11%) usr   0.00 ( 0%) sys   0.25 ( 8%) wall
 rest of compilation   :   0.04 ( 2%) usr   0.00 ( 0%) sys   0.16 ( 5%) wall
 TOTAL                 :   2.26             0.33             3.05

Also, I compile with these options:

g++ -g -pedantic -Wall

Thanks again!
Anna

Re: Suggestions for improving gcc 3.2 compilation speed?

[Karel Gardas]

On Fri, 7 Mar 2003, Mike Stump wrote:

> On Friday, March 7, 2003, at 03:09 AM, Biagio Lucini wrote:
> > Could you give me an example of a fast compiler? My only term of
> > comparison is the Intel one, and with it it takes ages to compile the
> > most
> > trivial program.
>
> I have a g++ compiler that is 5.6x faster than the current g++ when
> compiling large C++ code bases.  That's when compared to a g++ PCH,
> without it, more like 8x to 16x faster when PCH isn't used.  Work in
> progress, but it shows that g++ can be fast, if we want it to be.  For
> trivial files, small projects and single files, the speedup is 0.
>

I'm interested in testing it, but unfortunatelly it doesn't apply cleanly
(I suppose you are talking about main-trunk):

thinkpad:~/cvs/gcc/c++-multitrans/gcc$ patch -p0 < /tmp/multiunit.diffs
patching file tree.c
Hunk #1 succeeded at 96 (offset 1 line).
patching file cp/call.c
Hunk #1 succeeded at 5467 (offset -129 lines).
Hunk #2 succeeded at 5776 (offset -132 lines).
patching file cp/cp-tree.h
Hunk #1 succeeded at 3521 with fuzz 1 (offset -11 lines).
patching file cp/decl.c
Hunk #1 succeeded at 288 (offset -12 lines).
Hunk #2 succeeded at 3234 (offset -89 lines).
Hunk #3 succeeded at 3838 (offset -103 lines).
Hunk #4 succeeded at 9381 (offset -519 lines).
patching file cp/decl2.c
Hunk #1 succeeded at 3504 (offset -442 lines).
patching file cp/lex.c
Hunk #1 succeeded at 54 with fuzz 2 (offset -6 lines).
Hunk #2 FAILED at 684.
Hunk #3 succeeded at 685 with fuzz 1 (offset -483 lines).
1 out of 3 hunks FAILED -- saving rejects to file cp/lex.c.rej
patching file cp/semantics.c
Hunk #1 succeeded at 1772 (offset 86 lines).
Hunk #2 FAILED at 1878.
1 out of 2 hunks FAILED -- saving rejects to file cp/semantics.c.rej
thinkpad:~/cvs/gcc/c++-multitrans/gcc$

Against which version exactly is this patch?

Thanks,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: Suggestions for improving gcc 3.2 compilation speed?

[Mike Stump]

On Friday, March 7, 2003, at 11:28 AM, Zack Weinberg wrote:
> That's clever.  Do you think you could make this happen automatically
> when more than one input file is given on cc1(plus)'s command line?  I
> believe the Java front end does something like that already.

There are lots of possibilities.  Zero-compile, compiler notes into the 
.o file the compile line, doesn't do any work, the driver, when doing a 
link, noticed these zero-compile .o files, and then invokes the 
compiler with all the relevant details.  This preserves the current 
model and style of building.

Force the GUI development frontend to synth up such files (the ones 
with #pragma translationunit).

Insist that the compiler be given multiple .cc files on a single 
command line, if they want the speed up.

Re: Suggestions for improving gcc 3.2 compilation speed?

[Zack Weinberg]

Mike Stump <mrs@apple.com> writes:

> I have a g++ compiler that is 5.6x faster than the current g++ when
> compiling large C++ code bases.  That's when compared to a g++ PCH,
> without it, more like 8x to 16x faster when PCH isn't used.  Work in
> progress, but it shows that g++ can be fast, if we want it to be.  For
> trivial files, small projects and single files, the speedup is 0.
>
> The patches help understand the upper limit on speedups possible if we
> just work smarter with header files.
>
> To use, generate a file sorta like:
>
> #include "AboutWindow/AboutWindow.cp"
> #pragma translationunit "StatusBar/StatusBar.cp"
> #include "StatusBar/StatusBar.cp"
> #pragma translationunit "Preview/ColumnPreview.cp"
> #include "Preview/ColumnPreview.cp"
> [ ... ]
>
> and then time a -S build of it and compare against a -S build of all
> the individual files.

That's clever.  Do you think you could make this happen automatically
when more than one input file is given on cc1(plus)'s command line?  I
believe the Java front end does something like that already.

zw

Re: Suggestions for improving gcc 3.2 compilation speed?

[tm_gccmail]

On Fri, 7 Mar 2003, Karel Gardas wrote:

> On Fri, 7 Mar 2003, Biagio Lucini wrote:
> 
> > Could you give me an example of a fast compiler? My only term of
> > comparison is the Intel one, and with it it takes ages to compile the most
> > trivial program.
> 
> Maybe trivial, but with more complex progs it seems to be quite fast:
> http://gcc.gnu.org/ml/gcc/2003-03/msg00490.html
> 
> IIRC some gcc developer from apple (sorry that I forgot name) said that on
> Apple Metrowerks compilers were really fast.

The Metrowerks compilers IMHO don't have very good code generation.

When I was at Sega, I tried to help them with their compiler because the
emitted code was so bad. It would miss trivial CSE opportunities and had
numerous other problems.

If you're going to compare compilers, you need to pick one more on par
with gcc.

Toshi

Re: Suggestions for improving gcc 3.2 compilation speed?

[Mike Stump]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Friday, March 7, 2003, at 03:09 AM, Biagio Lucini wrote:
> Could you give me an example of a fast compiler? My only term of
> comparison is the Intel one, and with it it takes ages to compile the 
> most
> trivial program.

I have a g++ compiler that is 5.6x faster than the current g++ when 
compiling large C++ code bases.  That's when compared to a g++ PCH, 
without it, more like 8x to 16x faster when PCH isn't used.  Work in 
progress, but it shows that g++ can be fast, if we want it to be.  For 
trivial files, small projects and single files, the speedup is 0.

The patches help understand the upper limit on speedups possible if we 
just work smarter with header files.

To use, generate a file sorta like:

#include "AboutWindow/AboutWindow.cp"
#pragma translationunit "StatusBar/StatusBar.cp"
#include "StatusBar/StatusBar.cp"
#pragma translationunit "Preview/ColumnPreview.cp"
#include "Preview/ColumnPreview.cp"
[ ... ]

and then time a -S build of it and compare against a -S build of all 
the individual files.


[-- Attachment #2: multiunit.diffs --]
[-- Type: application/octet-stream, Size: 8983 bytes --]

Doing diffs in tree.c.~1~:
*** tree.c.~1~	Thu Feb 13 18:09:15 2003
--- tree.c	Sat Feb 15 08:02:58 2003
*************** static int next_decl_uid;
*** 95,100 ****
--- 95,106 ----
  /* Unique id for next type created.  */
  static int next_type_uid = 1;
  
+ int
+ get_next_decl_uid ()
+ {
+   return next_decl_uid;
+ }
+ 
  /* Since we cannot rehash a type after it is in the table, we have to
     keep the hash code.  */
  
--------------
Doing diffs in cp/call.c.~1~:
*** cp/call.c.~1~	Thu Jan 30 11:26:44 2003
--- cp/call.c	Sat Feb 15 14:10:45 2003
*************** equal_functions (fn1, fn2)
*** 5596,5601 ****
--- 5596,5610 ----
    return fn1 == fn2;
  }
  
+ 
+ static int
+ rejoust (cand1, cand2)
+      struct z_candidate *cand1, *cand2;
+ {
+   /* FIX this  */
+   return -1;
+ }
+ 
  /* Compare two candidates for overloading as described in
     [over.match.best].  Return values:
  
*************** tourney (candidates)
*** 5899,5904 ****
--- 5908,5925 ----
  	{
  	  if (fate == 0)
  	    {
+ 	      fate = rejoust (champ, challenger);
+ 	      if (fate == 1)
+ 		{
+ 		  challenger = challenger->next;
+ 		  continue;
+ 		}
+ 	      else if (fate == -1)
+ 		{
+ 		  champ = challenger;
+ 		  champ_compared_to_predecessor = 1;
+ 		  continue;
+ 		}
  	      champ = challenger->next;
  	      if (champ == 0)
  		return 0;
--------------
Doing diffs in cp/cp-tree.h.~1~:
*** cp/cp-tree.h.~1~	Sat Feb 15 06:00:41 2003
--- cp/cp-tree.h	Sat Feb 15 15:42:49 2003
*************** enum overload_flags { NO_SPECIAL = 0, DT
*** 3532,3537 ****
--- 3532,3551 ----
     ? TYPE_TI_TEMPLATE (NODE)				\
     : TYPE_NAME (NODE))
  
+ extern unsigned int first_decl_uid_in_unit;
+ 
+ static bool in_other_unit (tree);
+ 
+ static inline bool in_other_unit (tree t)
+ {
+   if (t == error_mark_node)
+     return 0;
+ 
+   if (DECL_UID (t) < first_decl_uid_in_unit)
+     return 1;
+   return 0;
+ }
+ 
  /* in lex.c  */
  
  extern void init_reswords PARAMS ((void));
--------------
Doing diffs in cp/decl.c.~1~:
*** cp/decl.c.~1~	Thu Feb 13 18:09:34 2003
--- cp/decl.c	Sat Feb 15 11:10:49 2003
*************** int adding_implicit_members = 0;
*** 300,305 ****
--- 300,307 ----
     processed.  */
  bool have_extern_spec;
  
+ unsigned int first_decl_uid_in_unit = 0;
+ 
  \f
  /* For each binding contour we allocate a binding_level structure
     which records the names defined in that contour.
*************** duplicate_decls (newdecl, olddecl)
*** 3321,3326 ****
--- 3323,3330 ----
        const char *errmsg = redeclaration_error_message (newdecl, olddecl);
        if (errmsg)
  	{
+ 	  if (in_other_unit (olddecl))
+ 	    return 0;
  	  error (errmsg, newdecl);
  	  if (DECL_NAME (olddecl) != NULL_TREE)
  	    cp_error_at ((DECL_INITIAL (olddecl)
*************** pushdecl (x)
*** 3937,3943 ****
  	  t = NULL_TREE;
  	  cp_error_at ("`%#D' used prior to declaration", x);
  	}
!       else if (t != NULL_TREE)
  	{
  	  if (different_binding_level)
  	    {
--- 3941,3948 ----
  	  t = NULL_TREE;
  	  cp_error_at ("`%#D' used prior to declaration", x);
  	}
!       else if (t != NULL_TREE
! 	       && ! in_other_unit (t))
  	{
  	  if (different_binding_level)
  	    {
*************** check_static_variable_definition (decl, 
*** 9895,9909 ****
       required.  */
    if (!ARITHMETIC_TYPE_P (type) && TREE_CODE (type) != ENUMERAL_TYPE)
      {
!       error ("invalid in-class initialization of static data member of non-integral type `%T'",
! 	     type);
!       /* If we just return the declaration, crashes will sometimes
! 	 occur.  We therefore return void_type_node, as if this was a
! 	 friend declaration, to cause callers to completely ignore
! 	 this declaration.  */
!       return 1;
      }
!   else if (!CP_TYPE_CONST_P (type))
      error ("ISO C++ forbids in-class initialization of non-const static member `%D'",
  	      decl);
    else if (pedantic && !INTEGRAL_TYPE_P (type))
--- 9900,9920 ----
       required.  */
    if (!ARITHMETIC_TYPE_P (type) && TREE_CODE (type) != ENUMERAL_TYPE)
      {
!       if (CLASS_TYPE_P (type) || TREE_CODE (type) == REFERENCE_TYPE)
! 	{
! 	  error ("invalid in-class initialization of static data member of non-integral type `%T'",
! 		 type);
! 	  /* If we just return the declaration, crashes will sometimes
! 	     occur.  We therefore return void_type_node, as if this was a
! 	     friend declaration, to cause callers to completely ignore
! 	     this declaration.  */
! 	  return 1;
! 	}
!       pedwarn ("invalid in-class initialization of static data member of non-integral type `%T'",
! 	       type);
!       return 0;
      }
!   if (!CP_TYPE_CONST_P (type))
      error ("ISO C++ forbids in-class initialization of non-const static member `%D'",
  	      decl);
    else if (pedantic && !INTEGRAL_TYPE_P (type))
--------------
Doing diffs in cp/decl2.c.~1~:
*** cp/decl2.c.~1~	Thu Feb 13 18:09:35 2003
--- cp/decl2.c	Sat Feb 15 11:25:26 2003
*************** ambiguous_decl (name, old, new, flags)
*** 3946,3952 ****
            val = NULL_TREE;
        }
          
!   if (!BINDING_VALUE (old))
      BINDING_VALUE (old) = val;
    else if (val && val != BINDING_VALUE (old))
      {
--- 3946,3956 ----
            val = NULL_TREE;
        }
          
!   if (!BINDING_VALUE (old)
!       || (! is_overloaded_fn (BINDING_VALUE (old))
! 	  && in_other_unit (BINDING_VALUE (old))
! 	  && val != 0 
! 	  && ! is_overloaded_fn (val)))
      BINDING_VALUE (old) = val;
    else if (val && val != BINDING_VALUE (old))
      {
--------------
Doing diffs in cp/lex.c.~1~:
*** cp/lex.c.~1~	Thu Feb 13 18:09:35 2003
--- cp/lex.c	Sat Feb 15 15:28:49 2003
*************** static void handle_pragma_unit PARAMS ((
*** 60,65 ****
--- 60,66 ----
  static void handle_pragma_interface PARAMS ((cpp_reader *));
  static void handle_pragma_implementation PARAMS ((cpp_reader *));
  static void handle_pragma_java_exceptions PARAMS ((cpp_reader *));
+ static void handle_pragma_translationunit PARAMS ((cpp_reader *));
  
  #ifdef GATHER_STATISTICS
  #ifdef REDUCE_LENGTH
*************** init_cp_pragma ()
*** 689,694 ****
--- 690,697 ----
  		       handle_pragma_implementation);
    cpp_register_pragma (parse_in, "GCC", "java_exceptions",
  		       handle_pragma_java_exceptions);
+   cpp_register_pragma (parse_in, 0, "translationunit",
+ 		       handle_pragma_translationunit);
  }
  
  /* Initialize the C++ front end.  This function is very sensitive to
*************** handle_pragma_java_exceptions (dfile)
*** 1165,1170 ****
--- 1168,1203 ----
      warning ("junk at end of #pragma GCC java_exceptions");
  
    choose_personality_routine (lang_java);
+ }
+ 
+ static void
+ handle_pragma_translationunit (dfile)
+      cpp_reader *dfile ATTRIBUTE_UNUSED;
+ {
+   tree fname = parse_strconst_pragma ("translationunit", 1);
+   const char *main_filename;
+ 
+   if (fname == (tree)-1)
+     return;
+   else if (fname == 0)
+     {
+       abort ();
+       main_filename = lbasename (input_filename);
+     }
+   else
+     main_filename = TREE_STRING_POINTER (fname);
+ 
+   if (0)
+     {
+       main_input_filename = main_filename;
+       first_global_object_name = 0;
+       weak_global_object_name = 0;
+       anonymous_namespace_name = 0;
+     }
+ 
+   first_decl_uid_in_unit = get_next_decl_uid ();
+ 
+   printf("saw unit %s\n", main_filename);
  }
  
  void
--------------
Doing diffs in cp/semantics.c.~1~:
*** cp/semantics.c.~1~	Thu Feb 13 18:09:36 2003
--- cp/semantics.c	Sat Feb 15 12:03:20 2003
*************** finish_parmlist (parms, ellipsis)
*** 1686,1691 ****
--- 1686,1700 ----
    return parms;
  }
  
+ bool
+ is_decl_again (tree t)
+ {
+   if (DECL_SOURCE_LINE (TYPE_NAME (t)) == lineno
+       && strcmp (DECL_SOURCE_FILE (TYPE_NAME (t)), input_filename) == 0)
+     return 1;
+   return 0;
+ }
+ 
  /* Begin a class definition, as indicated by T.  */
  
  tree
*************** begin_class_definition (t)
*** 1783,1789 ****
    /* If this type was already complete, and we see another definition,
       that's an error.  */
    else if (COMPLETE_TYPE_P (t))
!     duplicate_tag_error (t);
  
    /* Update the location of the decl.  */
    DECL_SOURCE_FILE (TYPE_NAME (t)) = input_filename;
--- 1792,1805 ----
    /* If this type was already complete, and we see another definition,
       that's an error.  */
    else if (COMPLETE_TYPE_P (t))
!     {
!       if (is_decl_again (t))
! 	{
! 	  /* This case is hard to recover from, punt for now.  */
! 	  error ("please add include guards to this file");
! 	}
!       duplicate_tag_error (t);
!     }
  
    /* Update the location of the decl.  */
    DECL_SOURCE_FILE (TYPE_NAME (t)) = input_filename;
--------------

Re: Suggestions for improving gcc 3.2 compilation speed?

[Anna Fowles-Winkler]

Out of curiousity, I compiled my application with Intel's c++ compiler, 
and it took 11 minutes.  (Again, 2.8 Ghz, 1 GB RAM).

Also, I'm not compiling with any optimizations with either g++ or 
Intel's compiler.

--Anna

Re: Suggestions for improving gcc 3.2 compilation speed?

[Michael S. Zick]

On Friday 07 March 2003 05:25 am, Lars Segerlund wrote:
>   I have a small idea, once upon a time people were using kilo lines per
> second as a measurement of compiler speed, and on a 68030 you could hit
> well above 10klps optimized code.
>
>   Perhaps we could report this metric ? 
Hmm...
Once upon a time programs didn't use a zillion templates from a STL.
But if the count could be broken down into:
Source Lines:
Included Lines:
	Lines read:
	Expanded lines out:
Template Include Lines:

Or some other subdivisions that would account for the different
processing paths of programs being compiled, it might be an
interesting number to report (-fline-counts?)

Mike

Re: Suggestions for improving gcc 3.2 compilation speed?

[Russell Shaw]

Lars Segerlund wrote:
> 
> Russell Shaw wrote:
> 
>> Anna Fowles-Winkler wrote:
>>
 >
 >  I like gcc, however I think this pinpoints the problem of using it for
 > real software developement, it's painfully slow and getting slower all
 > the time. When I get some time I will also look if I can give some help
 > in making it faster, however this is a problem since people are starting
 > to abandon gcc, ( for everything exept trivial stuff ).
 >
 >  Gcc would need a 50 % speedup in this case to be deemed usefull, and I
 > believe a speedup of 100%-200% would be necessary in order to put it on
 > par with most other compilers.
 >
 >  I just want to point out this in retrospect of the previous discussion
 > about compilation speed as a real issue, not to restart the debate.
 >
 >  / Lars Segerlund.

I haven't been on this list long enough to see all the speed discussions,
but have these tests been done after excluding makefile and build-script
processes? Has HDD accesses been measured?

With my 500MHz P-III, i see many compile stages lasting for 10s or more
when compiling a kernel or another gcc from source. I can't believe there's
that many cpu cycles used in purely compiling. I'd thought the actual
compilation time would be more like < %10 of the total time.
Borland C++ Builder speeds the compilation by caching pre-compiled headers.

Re: Suggestions for improving gcc 3.2 compilation speed?

[Lars Segerlund]

  I have a small idea, once upon a time people were using kilo lines per 
second as a measurement of compiler speed, and on a 68030 you could hit 
well above 10klps optimized code.

  Perhaps we could report this metric ? I know it has a lot of 
fallancies when it compares to comparing different sources, however it's 
a metric which is easy to interpret for a specific program ( being 
compiled ), and a high relevance for the end user.

  Also it would point out relative slowdowns if used on a gcc+libs build 
and then one could target problem areas to increase build speed in two 
way's, one inprove handling of that code, two rewrite to circumvent.

  Any thought's ?

  / Lars.

Biagio Lucini wrote:
> Could you give me an example of a fast compiler? My only term of
> comparison is the Intel one, and with it it takes ages to compile the most
> trivial program.
> 
> Biagio
> 
> On Fri, 7 Mar 2003, Lars Segerlund wrote:
> 
> 
>>  I like gcc, however I think this pinpoints the problem of using it for
>>real software developement, it's painfully slow and getting slower all
>>the time. When I get some time I will also look if I can give some help
>>in making it faster, however this is a problem since people are starting
>>to abandon gcc, ( for everything exept trivial stuff ).
>>
>>  Gcc would need a 50 % speedup in this case to be deemed usefull, and I
>>believe a speedup of 100%-200% would be necessary in order to put it on
>>par with most other compilers.
>>
>>  I just want to point out this in retrospect of the previous discussion
>>about compilation speed as a real issue, not to restart the debate.
>>
>>  / Lars Segerlund.
>>
> 
> 

Re: Suggestions for improving gcc 3.2 compilation speed?

[Lars Segerlund]

  Well,

   Borland comes to mind, as does Lattice ( althoug lattice was slow, 
gcc was much slower when I started using it ), a better question is what 
compiler is slower than gcc ? Even microsofts compiler and IDE is 
blazingly fast compared to gcc.

   We all had the comparison with tcc a while ago ( which is quite 
unfair ), but shows how much room for improvement there is.

  However it seem's to get better :-) ...

  / Regards, Lars

Biagio Lucini wrote:
> Could you give me an example of a fast compiler? My only term of
> comparison is the Intel one, and with it it takes ages to compile the most
> trivial program.
> 
> Biagio
> 
> On Fri, 7 Mar 2003, Lars Segerlund wrote:
> 
> 
>>  I like gcc, however I think this pinpoints the problem of using it for
>>real software developement, it's painfully slow and getting slower all
>>the time. When I get some time I will also look if I can give some help
>>in making it faster, however this is a problem since people are starting
>>to abandon gcc, ( for everything exept trivial stuff ).
>>
>>  Gcc would need a 50 % speedup in this case to be deemed usefull, and I
>>believe a speedup of 100%-200% would be necessary in order to put it on
>>par with most other compilers.
>>
>>  I just want to point out this in retrospect of the previous discussion
>>about compilation speed as a real issue, not to restart the debate.
>>
>>  / Lars Segerlund.
>>
> 
> 

Re: Suggestions for improving gcc 3.2 compilation speed?

[Karel Gardas]

On Fri, 7 Mar 2003, Biagio Lucini wrote:

> Could you give me an example of a fast compiler? My only term of
> comparison is the Intel one, and with it it takes ages to compile the most
> trivial program.

Maybe trivial, but with more complex progs it seems to be quite fast:
http://gcc.gnu.org/ml/gcc/2003-03/msg00490.html

IIRC some gcc developer from apple (sorry that I forgot name) said that on
Apple Metrowerks compilers were really fast.

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: Suggestions for improving gcc 3.2 compilation speed?

[Biagio Lucini]

Could you give me an example of a fast compiler? My only term of
comparison is the Intel one, and with it it takes ages to compile the most
trivial program.

Biagio

On Fri, 7 Mar 2003, Lars Segerlund wrote:

>
>   I like gcc, however I think this pinpoints the problem of using it for
> real software developement, it's painfully slow and getting slower all
> the time. When I get some time I will also look if I can give some help
> in making it faster, however this is a problem since people are starting
> to abandon gcc, ( for everything exept trivial stuff ).
>
>   Gcc would need a 50 % speedup in this case to be deemed usefull, and I
> believe a speedup of 100%-200% would be necessary in order to put it on
> par with most other compilers.
>
>   I just want to point out this in retrospect of the previous discussion
> about compilation speed as a real issue, not to restart the debate.
>
>   / Lars Segerlund.
>

Re: Suggestions for improving gcc 3.2 compilation speed?

[Lars Segerlund]

  I like gcc, however I think this pinpoints the problem of using it for 
real software developement, it's painfully slow and getting slower all 
the time. When I get some time I will also look if I can give some help 
in making it faster, however this is a problem since people are starting 
to abandon gcc, ( for everything exept trivial stuff ).

  Gcc would need a 50 % speedup in this case to be deemed usefull, and I 
believe a speedup of 100%-200% would be necessary in order to put it on 
par with most other compilers.

  I just want to point out this in retrospect of the previous discussion 
about compilation speed as a real issue, not to restart the debate.

  / Lars Segerlund.

Russell Shaw wrote:
> Anna Fowles-Winkler wrote:
> 
>> Hi Kaveh,
>>
>> I ran gcc 3.2.2 with the patch, and it took 15 minutes instead of 18 
>> minutes to compile my application.  That's a slight improvement, but I 
>> guess my ideal running time would be closer to 10 minutes.  Am I 
>> dreaming? :)
>>
>> I think at this point I'm either going to go back to 2.95.3, or 
>> consider a commercial compiler.
>>
>> Thanks to everyone for your support.
> 
> 
> Your build-system may be very slow if it uses 'make' and a lot of shell
> scripts and does a lot of file/header searching.
> 
> Try upgrading to scsi HDDs or try a better/faster build method (jam):
>   http://www.perforce.com/jam/jam.html
> 
> 
> 
> 
> 

Re: Suggestions for improving gcc 3.2 compilation speed?

[Kaveh R. Ghazi]

 > From: Anna Fowles-Winkler <awinkler@maad.com>
 > 
 > Hi Kaveh,
 > 
 > I ran gcc 3.2.2 with the patch, and it took 15 minutes instead of 18 
 > minutes to compile my application.  That's a slight improvement,

Looks like around 20% improvement.  I wouldn't call that "slight".
It's pretty hard to get that much better out of gcc, especially with a
two line patch. :-)


 > but I 
 > guess my ideal running time would be closer to 10 minutes.  Am I 
 > dreaming? :)

I don't know, how long does your code take to compile with 2.95.3 or
some other compiler?


 > I think at this point I'm either going to go back to 2.95.3, or consider 
 > a commercial compiler.
 > 
 > Thanks to everyone for your support.
 > --Anna
 > 
 > PS - My application is mixed C/C++, and is compiled with the C++ 
 > compiler.  It has about 300K lines of code (400K+ including comments, 
 > blank lines), and links to Motif libraries, among other things.

Would you please try one more thing?  I'd like you to take your
largest file (or the one that takes the longest to compile) and run
before and after tests with --time-report, then post the results.
That will tell us where the compiler is spending it's time and also
zero in on gcc performance rather than "make" performance.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Suggestions for improving gcc 3.2 compilation speed?

[Russell Shaw]

Anna Fowles-Winkler wrote:
> Hi Kaveh,
> 
> I ran gcc 3.2.2 with the patch, and it took 15 minutes instead of 18 
> minutes to compile my application.  That's a slight improvement, but I 
> guess my ideal running time would be closer to 10 minutes.  Am I 
> dreaming? :)
> 
> I think at this point I'm either going to go back to 2.95.3, or consider 
> a commercial compiler.
> 
> Thanks to everyone for your support.

Your build-system may be very slow if it uses 'make' and a lot of shell
scripts and does a lot of file/header searching.

Try upgrading to scsi HDDs or try a better/faster build method (jam):
   http://www.perforce.com/jam/jam.html

Re: Suggestions for improving gcc 3.2 compilation speed?

[Anna Fowles-Winkler]

Hi Kaveh,

I ran gcc 3.2.2 with the patch, and it took 15 minutes instead of 18 
minutes to compile my application.  That's a slight improvement, but I 
guess my ideal running time would be closer to 10 minutes.  Am I 
dreaming? :)

I think at this point I'm either going to go back to 2.95.3, or consider 
a commercial compiler.

Thanks to everyone for your support.

--Anna

PS - My application is mixed C/C++, and is compiled with the C++ 
compiler.  It has about 300K lines of code (400K+ including comments, 
blank lines), and links to Motif libraries, among other things.

Kaveh R. Ghazi wrote:

> > I've been running gcc 2.95.3 on a 1Ghz/512MB RAM PC running RedHat
> > 7.2. It takes 20 minutes to compile my application, so I recently got
> > a new computer to reduce the time I wait for compiles. This new
> > computer is a 2.8 Ghz CPU/1GB RAM running RedHat 8.0. Since RedHat 8.0
> > comes with gcc 3.2 I figured I'd give it a try. It takes 20 minutes to
> > compile my application. (!!!)
> > 
> > I'm a little frustrated that the compilation speed is so slow with gcc
> > 3.2, especially since this is a commercial application (i.e., this is
> > my job). Is there anything I can do to improve the compilation speed?
> > Will newer gcc releases be as fast as gcc 2.95.3 (or faster)? Or is my
> > best bet to stick with 2.95.3?
>
>With 1GB of RAM, try this patch it might help some.  But on machines
>with less memory it may cause thrashing, so it's not a general
>solution.
>
>I'd appreciate hearing from you what effect it has.
>
>		Thanks,
>		--Kaveh
>
>PS: What language is your app written in?
>
>
>diff -rup orig/egcc-3.2-CVS20030223/gcc/ggc-page.c egcc-3.2-CVS20030223/gcc/ggc-page.c
>--- orig/egcc-3.2-CVS20030223/gcc/ggc-page.c	2002-01-05 17:11:21.000000000 -0500
>+++ egcc-3.2-CVS20030223/gcc/ggc-page.c	2003-02-23 19:13:27.726803129 -0500
>@@ -344,11 +344,11 @@ static struct globals
>    this factor times the allocation at the end of the last collection.
>    In other words, total allocation must expand by (this factor minus
>    one) before collection is performed.  */
>-#define GGC_MIN_EXPAND_FOR_GC (1.3)
>+#define GGC_MIN_EXPAND_FOR_GC (2.0)
> 
> /* Bound `allocated_last_gc' to 4MB, to prevent the memory expansion
>    test from triggering too often when the heap is small.  */
>-#define GGC_MIN_LAST_ALLOCATED (4 * 1024 * 1024)
>+#define GGC_MIN_LAST_ALLOCATED (128 * 1024 * 1024)
> 
> /* Allocate pages in chunks of this size, to throttle calls to memory
>    allocation routines.  The first page is used, the rest go onto the
>  
>

Re: Suggestions for improving gcc 3.2 compilation speed?

[Anna Fowles-Winkler]

Joel Sherrill wrote:

>"Kaveh R. Ghazi" wrote:
>  
>
>> > I've been running gcc 2.95.3 on a 1Ghz/512MB RAM PC running RedHat
>> > 7.2. It takes 20 minutes to compile my application, so I recently got
>> > a new computer to reduce the time I wait for compiles. This new
>> > computer is a 2.8 Ghz CPU/1GB RAM running RedHat 8.0. Since RedHat 8.0
>> > comes with gcc 3.2 I figured I'd give it a try. It takes 20 minutes to
>> > compile my application. (!!!)
>> >
>> > I'm a little frustrated that the compilation speed is so slow with gcc
>> > 3.2, especially since this is a commercial application (i.e., this is
>> > my job). Is there anything I can do to improve the compilation speed?
>> > Will newer gcc releases be as fast as gcc 2.95.3 (or faster)? Or is my
>> > best bet to stick with 2.95.3?
>>
>>With 1GB of RAM, try this patch it might help some.  But on machines
>>with less memory it may cause thrashing, so it's not a general
>>solution.
>>    
>>
>
>Have you tried using some parallelism in your build?  I work on an 
>application with 425K lines of mostly C++ which we build for two 
>target OSes.  It takes about 20 minutes on a 2.4 Ghz dual Xeon
>with 2 GB RAM.  We added a -j option to make and the build time 
>dropped to a little under 8 minutes.  The parallel make keeps the
>CPU busy while the OS is accessing the disk to read source files
>and write objects.  The difference in CPU utilization is incredible.
>The non-parallel make only hit about 25% CPU utiliization.  The
>parallel version stays close to 100% for most of the build.
>  
>
Good thought.  I tried it this morning:  both compiles (with and without 
the -j make option) take 18 minutes (more officially timed then my 
glance at the clock timing).

--Anna

Re: Suggestions for improving gcc 3.2 compilation speed?

[Joel Sherrill]

"Kaveh R. Ghazi" wrote:
> 
>  > I've been running gcc 2.95.3 on a 1Ghz/512MB RAM PC running RedHat
>  > 7.2. It takes 20 minutes to compile my application, so I recently got
>  > a new computer to reduce the time I wait for compiles. This new
>  > computer is a 2.8 Ghz CPU/1GB RAM running RedHat 8.0. Since RedHat 8.0
>  > comes with gcc 3.2 I figured I'd give it a try. It takes 20 minutes to
>  > compile my application. (!!!)
>  >
>  > I'm a little frustrated that the compilation speed is so slow with gcc
>  > 3.2, especially since this is a commercial application (i.e., this is
>  > my job). Is there anything I can do to improve the compilation speed?
>  > Will newer gcc releases be as fast as gcc 2.95.3 (or faster)? Or is my
>  > best bet to stick with 2.95.3?
> 
> With 1GB of RAM, try this patch it might help some.  But on machines
> with less memory it may cause thrashing, so it's not a general
> solution.

Have you tried using some parallelism in your build?  I work on an 
application with 425K lines of mostly C++ which we build for two 
target OSes.  It takes about 20 minutes on a 2.4 Ghz dual Xeon
with 2 GB RAM.  We added a -j option to make and the build time 
dropped to a little under 8 minutes.  The parallel make keeps the
CPU busy while the OS is accessing the disk to read source files
and write objects.  The difference in CPU utilization is incredible.
The non-parallel make only hit about 25% CPU utiliization.  The
parallel version stays close to 100% for most of the build.

> I'd appreciate hearing from you what effect it has.
> 
>                 Thanks,
>                 --Kaveh
> 
> PS: What language is your app written in?
> 
> diff -rup orig/egcc-3.2-CVS20030223/gcc/ggc-page.c egcc-3.2-CVS20030223/gcc/ggc-page.c
> --- orig/egcc-3.2-CVS20030223/gcc/ggc-page.c    2002-01-05 17:11:21.000000000 -0500
> +++ egcc-3.2-CVS20030223/gcc/ggc-page.c 2003-02-23 19:13:27.726803129 -0500
> @@ -344,11 +344,11 @@ static struct globals
>     this factor times the allocation at the end of the last collection.
>     In other words, total allocation must expand by (this factor minus
>     one) before collection is performed.  */
> -#define GGC_MIN_EXPAND_FOR_GC (1.3)
> +#define GGC_MIN_EXPAND_FOR_GC (2.0)
> 
>  /* Bound `allocated_last_gc' to 4MB, to prevent the memory expansion
>     test from triggering too often when the heap is small.  */
> -#define GGC_MIN_LAST_ALLOCATED (4 * 1024 * 1024)
> +#define GGC_MIN_LAST_ALLOCATED (128 * 1024 * 1024)
> 
>  /* Allocate pages in chunks of this size, to throttle calls to memory
>     allocation routines.  The first page is used, the rest go onto the

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Suggestions for improving gcc 3.2 compilation speed?

[Kaveh R. Ghazi]

 > I've been running gcc 2.95.3 on a 1Ghz/512MB RAM PC running RedHat
 > 7.2. It takes 20 minutes to compile my application, so I recently got
 > a new computer to reduce the time I wait for compiles. This new
 > computer is a 2.8 Ghz CPU/1GB RAM running RedHat 8.0. Since RedHat 8.0
 > comes with gcc 3.2 I figured I'd give it a try. It takes 20 minutes to
 > compile my application. (!!!)
 > 
 > I'm a little frustrated that the compilation speed is so slow with gcc
 > 3.2, especially since this is a commercial application (i.e., this is
 > my job). Is there anything I can do to improve the compilation speed?
 > Will newer gcc releases be as fast as gcc 2.95.3 (or faster)? Or is my
 > best bet to stick with 2.95.3?

With 1GB of RAM, try this patch it might help some.  But on machines
with less memory it may cause thrashing, so it's not a general
solution.

I'd appreciate hearing from you what effect it has.

		Thanks,
		--Kaveh

PS: What language is your app written in?


diff -rup orig/egcc-3.2-CVS20030223/gcc/ggc-page.c egcc-3.2-CVS20030223/gcc/ggc-page.c
--- orig/egcc-3.2-CVS20030223/gcc/ggc-page.c	2002-01-05 17:11:21.000000000 -0500
+++ egcc-3.2-CVS20030223/gcc/ggc-page.c	2003-02-23 19:13:27.726803129 -0500
@@ -344,11 +344,11 @@ static struct globals
    this factor times the allocation at the end of the last collection.
    In other words, total allocation must expand by (this factor minus
    one) before collection is performed.  */
-#define GGC_MIN_EXPAND_FOR_GC (1.3)
+#define GGC_MIN_EXPAND_FOR_GC (2.0)
 
 /* Bound `allocated_last_gc' to 4MB, to prevent the memory expansion
    test from triggering too often when the heap is small.  */
-#define GGC_MIN_LAST_ALLOCATED (4 * 1024 * 1024)
+#define GGC_MIN_LAST_ALLOCATED (128 * 1024 * 1024)
 
 /* Allocate pages in chunks of this size, to throttle calls to memory
    allocation routines.  The first page is used, the rest go onto the

Re: Suggestions for improving gcc 3.2 compilation speed?

[Matt Austern]

On Thursday, February 27, 2003, at 03:05 PM, Anna Fowles-Winkler wrote:

> Hi,
>
> I've been running gcc 2.95.3 on a 1Ghz/512MB RAM PC running RedHat 
> 7.2. It takes 20 minutes to compile my application, so I recently got 
> a new computer to reduce the time I wait for compiles.  This new 
> computer is a 2.8 Ghz CPU/1GB RAM running RedHat 8.0.  Since RedHat 
> 8.0 comes with gcc 3.2 I figured I'd give it a try.  It takes 20 
> minutes to compile my application. (!!!)
>
> I'm a little frustrated that the compilation speed is so slow with gcc 
> 3.2, especially since this is a commercial application (i.e., this is 
> my job).  Is there anything I can do to improve the compilation speed? 
> Will newer gcc releases be as fast as gcc 2.95.3 (or faster)?  Or is 
> my best bet to stick with 2.95.3?

We're doing a lot of work on improving compilation speed for 3.3 and 
3.4.  We could always use more help, though!

			--Matt

Suggestions for improving gcc 3.2 compilation speed?

[Anna Fowles-Winkler]

Hi,

I've been running gcc 2.95.3 on a 1Ghz/512MB RAM PC running RedHat 7.2. 
 It takes 20 minutes to compile my application, so I recently got a new 
computer to reduce the time I wait for compiles.  This new computer is a 
2.8 Ghz CPU/1GB RAM running RedHat 8.0.  Since RedHat 8.0 comes with gcc 
3.2 I figured I'd give it a try.  It takes 20 minutes to compile my 
application. (!!!)

I'm a little frustrated that the compilation speed is so slow with gcc 
3.2, especially since this is a commercial application (i.e., this is my 
job).  Is there anything I can do to improve the compilation speed? 
 Will newer gcc releases be as fast as gcc 2.95.3 (or faster)?  Or is my 
best bet to stick with 2.95.3?

Thanks in advance,
Anna