Re: gcc compile-time performance

[Marc Espie <espie at nerim dot net>]

On Sun, May 19, 2002 at 01:52:25PM +0100, Neil Booth wrote:
> Marc Espie wrote:-
> 
> > If multibyte support is that expensive, I believe that providing two
> > versions of the preprocessor, one multibyte, the other not, selectable
> > at runtime, would be a very good idea.
> 
> That's two of each compiler now 8-)  There is no separate CPP for
> GCC >= 3.2.
> 

Do you take me for an idiot ? Of course I know that :)

Now, maybe you can figure out what I meant.

Specifically, there ought to be a reasonable interface to the preprocessor,
and I would tend to think it ought to be feasible to just swap one set of
preprocessor functions to another.  That's right, that means settings
things up so that both preprocessors are part of gcc.
I assume that most things will be opaque to the compiler itself: after all,
all it should see would be a set of tokens, with opaque ways to compare 
values (where compare is to be taken in an abstract way, e.g., hash table ?),
and a way to spew out token values (identifiers).

If I understand things correctly, the bandwidth bottleneck is at the front
of the preprocessor. Tokens are already much easier on the processing
power. Sure, getting through a function pointer may slow things down a bit,
but I don't think it will slow things down that bad, and definitely not a
two-fold slow-down, as you seem to imply ubiquitous multibyte support would
imply...