This is the mail archive of the
mailing list for the GCC project.
Re: gcc compile-time performance
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: law at redhat dot com
- Cc: Robert Dewar <dewar at gnat dot com>, gdr at codesourcery dot com,mark at codesourcery dot com, gcc at gcc dot gnu dot org, scott at coyotegulch dot com
- Date: Sat, 18 May 2002 16:09:07 -0400
- Subject: Re: gcc compile-time performance
- References: <20020518171850.8973EF2A59@nile.gnat.com> <email@example.com>
On Sat, May 18, 2002 at 11:48:11AM -0600, firstname.lastname@example.org wrote:
> In message <20020518171850.8973EF2A59@nile.gnat.com>, Robert Dewar writes:
> > > In order to support those uses, and to be competitive with other
> > > compilers, we do need to improve the speed of the compiler. I've heard
> > > this from too many real world customers with spending authority to
> > > believe any different.
> > The question is can you find ways to make substantial increases in speed.
> > I still don't see it being worthwhile to flail away looking at profiles and
> > tingering with conditionals. You are only going to get 10-30% that way
> > and it is not going to be enough to be significant.
> I disagree strongly. We've got customers where a 30% improvement in
> compile-time means cutting a day off their build cycles. I don't know
> precisely how much time it would cut off (for example) a build of RHL, but
> I would bet it would be enough to send our OS team into a state of ecstasy.
Absolutely seconded. Even a minimal build cycle is about six hours for
our product, distributed over a substantial number of machines.
Compile speed is very important to us as it grows.
(Although fixing Solaris [with a hammer] might still get us more
advantage than fixing GCC...)
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer