Re: Faster compilation speed

[Linus Torvalds <torvalds at transmeta dot com>]

In article <20020809200413.46719.qmail@web21403.mail.yahoo.com> you write:
>Build speeds are most helped by minimizing the number
>of files opened and closed during the build.

I _seriously_ doubt that.

Opening (and even reading) a cached file is not an expensive operation,
not compared to the kinds of run-times gcc has.  We're talking a few
microseconds per file open at a low level.  Even parsing it should not
be that expensive, especially if the preprocessor is any good (and from
all I've seen, these days it _is_ good).

I strongly suspect that what makes gcc slow is that it has absolutely
horrible cache behaviour, a big VM footprint, and chases pointers in
that badly cached area all of the time.

And that, in turn, is probably impossible to fix as long as gcc uses
garbage collection for most of its internal memory management.  There
just aren't all that many worse ways to f*ck up your cache behaviour
than by using lots of allocations and lazy GC to manage your memory. 

The problem with bad cache behaviour is that you don't get nice spikes
in specific places that you can try to optimize - the cost ends up being
spread all over the places that touch the data structures. 

The problem with trying to avoid GC is that if you do that you have to
be careful about your reference counts, and I doubt the gcc people want
to be that careful, especially considering that the code-base right now
is not likely to be very easy to convert.

(Plus the fact that GC proponents absolutely refuse to see the error of
their ways, and will flame me royally for even _daring_ to say that GC
sucks donkey brains through a straw from a performance standpoint.  If
order to work with refcounting, you need to have the mentality that
every single data structure with a non-local lifetime needs to have the
count as it's major member)

			Linus