This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compilation time (was Re: GCC 3.3)
- From: Phil Edwards <phil at jaj dot com>
- To: "Timothy J. Wood" <tjw at omnigroup dot com>
- Cc: Matt Austern <austern at apple dot com>,Daniel Berlin <dberlin at dberlin dot org>,Mark Mitchell <mark at codesourcery dot com>,"Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, gcc at gcc dot gnu dot org,bkoz at redhat dot com
- Date: Wed, 30 Apr 2003 14:54:53 -0400
- Subject: Re: Compilation time (was Re: GCC 3.3)
- References: <EDF03323-7AA2-11D7-AB74-000393B2ABA2@apple.com> <DE0B5339-7AA5-11D7-9F05-000A9567A046@omnigroup.com>
On Tue, Apr 29, 2003 at 05:51:24PM -0700, Timothy J. Wood wrote:
>
> Maybe this is obvious, but I'd also add:
>
> 6. Don't use 'configure', 'make' or any other complex glue code in the
> timing tests. You want to test the compiler time, not the whole build
> process. This will help in detecting small variations in compiler
> speed by making the percentage of time spent in the compiler larger.
Right. More to the point, I don't want to spend exclusive time testing
a build process which itself is changing rapidly, and then bill that time
to the compiler.
I do plan on timing the configure step by itself, on the side, just for
additional shared misery.
> If you want to use some project for testing that builds using using a
> bunch of glue, maybe do it once via the glue and capture the emitted
> commands, building a trivial shell script out of them.
Either that, or assume that for, e.g., a released package, the Makefile
isn't changing either, and simply ignore the constant overhead. We're not
looking for absolute numbers, after all, but steady changes.
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams