This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Precompiled headers (or other speed ups)
- To: dewar at gnat dot com
- Subject: Re: Precompiled headers (or other speed ups)
- From: Stan Shebs <shebs at apple dot com>
- Date: Tue, 09 Jan 2001 15:42:39 -0800
- CC: amep at softhome dot net, gcc at gcc dot gnu dot org
- References: <20010109225504.7663A34D87@nile.gnat.com>
dewar@gnat.com wrote:
>
> [...]
> These days, it is probably 1 million lines/minute vs 100,000 lines/minute
> or something like that and it does not matter at all.
>
> So absolute speeds are important.
OK, there is probably some level at which the absolute speed
difference is unnoticeable, but we're nowhere close to that.
Unlike the Linux situation, where GCC is effectively a "monopoly"
since there aren't really any other compiler choices, on Macs
developers can choose between Metrowerks and GCC, and they're
astonished that anybody would use a compiler as slow as GCC.
> By comparison, if you use GNAT to compile the DEC starlet library, which
> is 64,000 lines of very dense declarations, that is with'ed by typical
> applications, much as a C++ compiler eats headers with #include, it takes
> a few seconds on a fast PC.
Watch out for those "few seconds"! - if you're compiling 360 source
files, 10 seconds/compile adds up to a full hour. To be as fast as MW,
you have to get done with each file in under a second.
> When I said that I did not consider fast compilation to be a major goal
> of gcc, I was talking about the back end and code generator, but if I
> understand things clearly, it is the C++ *front end* that is eating up
> time here, and that seems surprising.
C gets hit too. I have to stay focussed on getting CVS GCC to bootstrap
on Darwin systems right now, but once that's in, I'll be able to go
back for another round of profiling. A year ago, most of the wall
clock time in the hour-long builds I was measuring disappeared into
yyparse and friends, but that was 2.95, and I'm more interested in the
current code now.
Stan