Re: GCC 3.0 Status Report

[Daniel Berlin <dberlin at redhat dot com>]

Geoff Keating <geoffk@geoffk.org> writes:

> Mark Mitchell <mark@codesourcery.com> writes:
> 
> >   In the short term, we will focus on compile-time performance, 
> >   especially in C++.  At that point, application testing will 
> >   become the major focus.  Performance of the generated code
> >   will be a greater focus of the 3.1 release.
> 
> Hi Mark,
> 
> I have some news for you, which might be good or might be bad, your
> choice :-).
> 
> Jason Merrill took over the PCH stuff from where I left it, and
> finished the C++ support.  Based on the numbers I had for C, I
> expected a 2x or 3x speed improvement, which is nice but not
> earth-shattering.  However, we have some new numbers from Daniel
> Berlin which indicates that the speed improvement is more on the order
> of 20x, when compiling KDE; I guess I just didn't realize how huge C++
> headers were.   Dan says 'I can now compile all of KDE in the time it
> took to compile one file before'.

One directory, not one file.
It's "almost" that fast, however.

Even on secondary platforms, like BeOS (the original tests were done
on my powerbook running powerpc-linux), i see similar speed
improvements (a factor of 15 to 24).

For instance, one large C++ project i work on, it takes at least 30 seconds
just to finish including all the headers on quite a few of the
files. This means I actually ended 
up having to stuff as many implementations of misc classes as possible
in single files, or files where they didn't belong, to avoid massive compilation times. 
For a test, I seperated these misc classes out,and without PCH, it
takes about 5-10  minutes to compile these 10 simple (< 100 lines) class
implementations, that happen to require a lot of headers
(not my fault, nor could it really be avoided. A lot of mixins and whatnot).

Even doing a single one of these files without PCH takes about a
minute to two minutes.
With PCH on, it takes 4 seconds per file, including the time from
start to object file appearing.
And fork is pretty slow on BeOS  (it's one of those "takes a while to
run configure" platforms).
I'm not joking.

Most of the 4 seconds seems to get spent in a GC right after it sees the first
thing in the implementation (I assume it's starting to lazy load
things from the PCH headers at this point and there is a ggc_collect
where it isn't the best idea anymore, or PCH is creating a lot of
objects that aren't goint to be gotten rid of, since the GC reclaims
just about nothing).


On C programs, I see about the performance improvement you do (I took
evolution, 
precompiled  glib, gtk, and the includes that are most used in
evolution (camel.h, etc), and got a 2-3x compile time improvement).
> So my proposal is that compile-time performance for the 3.0 release be
> downgraded in importance; that we move as much as possible of PCH into
> the mainline FSF tree as soon as possible, so that others can work on
> it and so that it can be integrated into the 3.1 release; and that the
> main feature of the 3.1 release will be compile-time speed
> improvements, much of which will be provided by precompiled headers.
> 
> Of course, there are some things that could be done that would speed
> up 3.0 and speed up PCH even more; for instance, GC is one of the
> things that take more time with PCH because PCH creates lots of
> permanent objects right at the start of compilation, so improvements
> to how GC handles permanent objects will be a big win.

This must be what I just noticed with the GC taking most of the 4
seconds.

-- 

Hackers have kernel knowledge.