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

i don't think anybody else undestands this method of coding either.

precompiling headers as a performance hack is akin to this kind of thinking:

	patient:	doctor, doctor it hurts when i do this.
	doctor:   i think you need a special brace. there's a specialist for these
		kind of problems. let me write you an order...

instead of

	patient:	doctor, doctor it hurts when i do this.
	doctor:   don't do that then.

to amuse yourself. try this.

	; gcc -E somefile.c
	; wc -l somefile.i

this is especially fun on a glibc machine. but code like this is not the reason gcc is so slow.
try tcc, lcc, or icc on the same source code.

- erik

p.s. i've got to say one thing in gcc's favor. it was way the heck better than
any other compiler i had available when it was first written. it actually did
prototypes and warned if things didn't match. i guess it's been all downhill
since gcc-1.38

On Sat Mar 25 19:47:10 CST 2006, jmk@plan9.bell-labs.com wrote:

> 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