This is the mail archive of the
mailing list for the GCC project.
Re: gcc compile-time performance
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Robert Dewar <dewar at gnat dot com>, "gdr at codesourcery dot com" <gdr at codesourcery dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "scott at coyotegulch dot com" <scott at coyotegulch dot com>
- Date: Sat, 18 May 2002 10:28:07 -0700
- Subject: Re: gcc compile-time performance
- References: <20020518171850.8973EF2A59@nile.gnat.com>
--On Saturday, May 18, 2002 01:18:50 PM -0400 Robert Dewar <firstname.lastname@example.org>
>> 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.
Agreed. You need to look for order-of-magnitude improvements -- of which
there are definitely some to be had in G++. Precompiled headers, already
being worked on, is one excellent example; for many programs this technique
has been shown to make a huge difference.
These programs are getting bigger at about the rate of Moore's law,
based on my observations over the last five years, so we can't depend
on that to get the compiler off the hook.
Fundamentally, we have existence proofs: there are C++ compilers that
run markedly faster than G++ while providing a roughly equivalent
feature set. Some use different compilation models; by "feature set"
I mean "are at least equally standard conformant and generate code that
is at least equally fast". (Obviously, that's an imprecise criteria,
but it will serve.)
I'm about to check in a change to the Java front end that improves its
compile-time performance by approximately 80% when compiling the Java
runtime library on a system of interest to me. This isn't a hard change;
just a little computer science 101. David Miller yesterday found a way
to speed up the C compiler compiling itself by about 13% on some files,
also with a small change. Both of these are *algorithmic* changes; we
looked at the profiles, and then changed the algorithms around to get
the same results in a much faster way.
There are still lots of n^2 algorithms in GCC/G++. I know this not by
staring at the code, but by compiling real customer code and watching
what happens. Fixing these things will give order-of-magnitude
speedups for those programs.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com