This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
compile speed [was: gcc 3.5 integration branch proposal]
Alexandre Oliva wrote:
Err... And under what kind of logic is getting the compiler slower
not a waste of time for every GCC developer (that has to bootstrap and
test the whole thing for every patch) and user (that runs GCC to build
their own applications).
Of course getting the compiler slower is a "bug". But priorities
and resources are limited. A faster compiler is obviously desirable,
but how much effort should be spent on it? And who should do it?
> So we're actually imposing a
tax on everybody who wants to use the newer compiler by not caring
about its performance.
Of course we care. It's just a hard problem.
I know Apple has put a lot of effort on speeding up the compiler, and
I can only find it sad that such efforts are fundamentally
incompatible with the relatively-scalable approach to speeding builds
up, namely, the use of compiler farms with distcc, Mosix or similar
techniques.
(1) Counting on distributed builds does not help the lone developer
working on a single desktop or laptop. The people who cannot afford
faster CPUs are often the same people who don't have access to scads
of semi-idle locally-networked CPUs.
(2) Shipping pre-processed source adds non-trivial overheads: Extra
file writes, extra reading, extra lexing, shipping large pre-processed
source to another machine. You'd get a better speed-up by shipping
just each source file. For the header files there are multiple solutions:
(a) consistent build environments;
(b) a local copy of the client's /usr/include (disk space is cheap);
(c) shipping header files on demand and caching them.
Note that the compile server provides automatic support for (c);
it saves the text of the header files it has seen.
Not to say that distcc etc isn't useful, but I think it's a stop-gap,
not a real solution, and it doesn't help solve the real problems.
--
--Per Bothner
per@bothner.com http://per.bothner.com/