Re: Compilation time (was Re: GCC 3.3)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Matt Austern <austern@apple.com> writes:

| On Tuesday, April 29, 2003, at 12:30  PM, Phil Edwards wrote:
| 
| > I've added timing to the autocrasher.  Look for "TIME::" followed by
| > real
| > (wall clock), user, and system seconds in the logs.  It'll start
| > appearing
| > in the next 31 minutes to 7 days, depending on which build you're
| > examining.
| 
| Terrific idea!

Indeed!

[...]

| I've got some specific suggestions, some of which you've probably
| thought of already:
| 
|   1. Compile an unchanging piece of source code.  Compiler bootstrap
| is a poor test, for example, because you're never timing the same
| thing twice.

Completely agreed; although bootstrapping the compiler might give
some indication on slowdown :-)  

There are some free software out there known to trash the compiler
(e.g. C++ front-end) to death. Qt and KDE sources are popular examples
-- compiling Qt without -ftime-report takes about an hour (and about
thrice that time with -ftime-report) on my pentium 4 (2GHz) box
running a GNU/Linux system.  

[...]

|   3. Just to state the obvious, even though I know you know this
| already: run on an unloaded system.
|   4. Compile the test case five times, and throw away the first
| result.  Rationale: at least on some OSs, the result the first time
| you do the compilation is too noisy.  It's dominated by uninteresting
| details of what the caches happened to look like before you started
| the test.  ("Five" is slightly arbitrary, but you should at least have
| three results that you're not throwing away.)

I completely agree with both points.  At least, they match my
experience with the name lookup issue.  I don't know if Phil is
planning to monitor timing with -ftime-report, but I think that would
be a valuable information.

-- Gaby