From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1388b3a83891b000d624805b51308b94@plan9.bell-labs.com>
Date: Sat, 25 Mar 2006 20:46:00 -0500
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] new compilers
In-Reply-To: <34ae256d4297ee458f40543f2c83db2d@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 2148d6ea-ead1-11e9-9d60-3106f5b1d025

On Sat Mar 25 16:57:42 EST 2006, quanstro@quanstro.net wrote:
> eighty-megs and constantly swapping. and that's just the editor.
>
> if you look at the apple link i couldn't resist cluttering the list with,
> you'll love some of the ways they work around the fact that gcc is slooow.
> precompiled headers, speculative compiling (you saved a c file, we'll
> compile it now, just in case you might need it), distcc, etc.
>
> that's not to mention the bizzare workarounds to their slow linker.
>
> - erik

I find the notion of pre-compiled headers for anything other than
a very special situation rather odd. Although the example given in
the link is trivial it demonstrates an unthinking inefficiency we
see all too often in practice:

	there's a file foo.c which has an accompanying file foo.h which
	is only ever included in foo.c

This is a poor idea in many ways and is perhaps one of the reasons
we see all these other things being necessary to make the user believe
that things are happening faster.

Recently I was poking around in a multi-file open source driver and
came across more than one instance of the following which pulled me
up short (names changed to protect the guilty):

	foo.h contains the following:

		#define THING {					\
		{ 1234, XXX_YY0, ZZZ0 },		\
		{ 5678, XXX_YY1, ZZZ1 },		\
		... 200 more of these ...
		}

	and is only included in foo.c which contains one instance of
	its use:

		static const struct
		thing thing_table[] = THING;

It would never occur to me to #define a table like that. Age, I
suppose.

--jim