This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc and compiling speed
- From: Theo de Raadt <deraadt at cvs dot openbsd dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, tech at openbsd dot org, Marc Espie <espie at quatramaran dot ens dot fr>, "gcc at gcc dot gnu dot org List" <gcc at gcc dot gnu dot org>
- Date: Sun, 29 Feb 2004 20:46:56 -0700
- Subject: Re: gcc and compiling speed
> > > Marc,
> > > Now I know you have been asked before every time you bring up on the
> > > GCC's mailing list about a set of preprocessed source for openbsd so
> > > that the speed of GCC will improve.
> >
> > How will this improve the speed of gcc?
> >
> > Are pre-processed headers the way that gcc3 is going to recover
> > the speed that it has lost?
>
> I found pretty Andrew's request very confusingly worded (sorry
> Andrew!), so let me rephrase it: preprocessed (-E, -save-temps) output
> for specific test cases that have slowed down. This is what people ask
> Marc for every time he reports slowdown numbers, and so far he hasn't
> provided any.
Is include file parsing a time critical component of gcc?
Is it a part that has slowed down a lot?
Quite frankly, I bet that cpp performance is entirely lost in the
noise...
> Not that we're disputing that GCC has slowed down. But without
> specific testcases that have regressed, it's hard to do anything about
> it.
Please.... an entire operating system compiles slower, on every
architecture we have tested it, and I have not heard of any case which
compiles faster (except sha1.c on sparc cpus, where gcc got into some
optimizer loop).