Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: Why are character arrays special (e
Message-ID: <1875@dataio.Data-IO.COM>
Date: 13 Feb 89 20:04:43 GMT
References: <19742@uflorida.cis.ufl.EDU> <225800126@uxe.cso.uiuc.edu> <1989Feb10.191041.12109@utzoo.uucp>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 31

In article <1989Feb10.191041.12109@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>I'm not
>in love with X3J11 trigraphs, but the issue isn't worth all the fuss that's
>been made about it.  At worst they are a minor and fairly benign mistake.)

The trouble with trigraphs is that they, along with the 'phases of
translation' rules, require an extra test for each character of source
read. A perfect scanner examines each source character exactly once, thus
we can measure the perfection of a scanner by on average how many times
each character is tested. A good scanner is about 1.1 on this scale.
Trigraphs push it over 2.0.

The reason this is a problem is because most of the time spent in a
compiler is in the reading of source text and splitting it into tokens.
(If this isn't so, then your symbol table implementation is botched or
something else is.) I've found in my compiler (Zortech) that ONE extra
instruction executed per char read slows down the compiler by 5 to 10%.

It's irritating to have to implement a feature that nobody in their right
mind is going to use, and that has such a negative impact on the product.

So who cares about 10%? I do, a large percentage of my life is spent
waiting for compiles. My customers do too, it's a big issue for them.
Besides, 10% here, 10% there, 15% somewhere else, and it adds up to
a pig for a compiler. Programs are made fast by squeezing everywhere
possible (yes, I use profilers).

To digress for a moment, I'm well aware of the rule that 90% of the
execution time is spent in 10% of the code. This is true, however, of
programs BEFORE profiling and fixing of that 10% occurs. Things flatten
out a lot after that.