This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suggestions for improving gcc 3.2 compilation speed?
"Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu> writes:
> > From: Anna Fowles-Winkler <awinkler at maad dot 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 at geoffk dot org>