This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Faster compilation speed
- From: Neil Booth <neil at daikokuya dot co dot uk>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: Stan Shebs <shebs at apple dot com>, Noel Yap <yap_noel at yahoo dot com>,Mike Stump <mrs at apple dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 9 Aug 2002 23:23:30 +0100
- Subject: Re: Faster compilation speed
- References: <3D543E54.4@apple.com> <137FBE8A-ABE6-11D6-9511-00039390FFE2@apple.com>
Ziemowit Laski wrote:-
> >Is this assertion based on empirical measurement, and if so, for what
> >source code and what system? For instance, the longest source file
> >in GCC is about 15K lines, and at -O2, only a small percentage of
> >time is spent messing with files. If I use -save-temps on cp/decl.c on
> >one of my (Linux) machines, I get a total time of about 38 sec from
> >source to asm. If I just compile decl.i, it's about 37 sec, so that's
> >1 sec for *all* preprocessing, including all file opening/closing.
>
> Since the preprocessor is integrated, I don't think you can separate
> the timings in this way. :( A 'gcc3 -E cp/decl.c -o decl.i' would
> probably be more meaningful.
It is separated with the timing stuff.
Your test is not good: it tests time to output. It is well-known
that current CPP output is quite slow; on Linux this is largely a
Glibc problem. CPP output can be 50% of preprocessing time, which
when you think about it is quite illogical. However, it can be
made much faster, and I will do this eventually.
Since we use an integrated CPP, timing output is kind of irrelevant
(and vastly overstates CPP time). Current CPP provides tokens to
the parser far, far faster than cccp did via a temporary file and
a duplicated lexer in the front end (not to mention other advantages,
like precise token location information).
Neil.