This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: compile time regressions (was: merging for 3.4)
- From: Jan Hubicka <jh at suse dot cz>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: Mike Stump <mrs at apple dot com>, Benjamin Kosnik <bkoz at redhat dot com>,Dan Nicolaescu <dann at ics dot uci dot edu>, pfeifer at dbai dot tuwien dot ac dot at,echristo at redhat dot com, hubicka at ucw dot cz, jbuck at synopsys dot com,dnovillo at redhat dot com, mark at codesourcery dot com,gdr at integrable-solutions dot net, pcarlini at unitus dot it,libstdc++ at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 11 Dec 2002 00:06:25 +0100
- Subject: Re: compile time regressions (was: merging for 3.4)
- References: <20021210203302.GA12830@daikokuya.co.uk> <D22E59AD-0C8C-11D7-988A-000393941EE6@apple.com> <20021210222355.GB24303@daikokuya.co.uk>
> Mike Stump wrote:-
>
> > No, no, you have it backwards... PCH is going to expose all that slow
> > code that should be fast, that has to be fast, so that we can fix it.
> > By being 12x faster, or just 2x faster, there is _much_ less room to be
> > slow, not more, really.
>
> But slow code in things that PCH elides won't get exposed by the very
> nature of PCH. e.g. drastic CPP slowdowns (not gonna happen!), or say
> the parser.
I don't think so. It will make parser to do about comparable amount of
work to backend, so it will bring us into more realistic picture. Right
now for certain class of C++ code it is almost uninteresting to optimize
backend becuase parsing is so slow. Not so for Java, fortran and many C
programs.
There is lots of time wasted in all parts of GCC (yes, CPP is now
probably the very notable exception :)
And PCH is not improtant only because of precompiled headers. It is
first step towards whole program optimization that will bring all sorts
of new performance problem, so I am not affraid that we will once feel
that GCC is fast.
Honza
>
> Neil.