Re: [RFC] Symbol Separation - Debugging

[Matt Austern <austern at apple dot com>]

On Tuesday, July 1, 2003, at 6:13PM, Devang Patel wrote:

> On Tuesday, July 1, 2003, at 5:54 PM, Zack Weinberg wrote:
>
> > Neil Booth <neil@daikokuya.co.uk> writes:
> >
> > > [snip]
> > > Before cppfiles.c is further obfuscated, it would be nice if
> > >
> > > 1) PCH worked reliably, and
> > > 2) Geoff posted his patch that's "so good you can't argue", or we
> > >    do what I suggested about #import.
> >
> > Agree 100%.
>
> But this symbol separation is not related to #import implementation.
> It does not change it. It just asks cpp to find foo.cinfo
> while searching foo.h. It does not worry about how cpp finds foo.h
> or find.cinfo or whatever.
>
> I do not see why we want to block it until Geoff re-writes #import.
> Or do we have an agreement that cppfiles.c will stay in frozen state
> for massive and delicate changes until #import rewrite ?
>
> I will make appropriate changes in my final patch as per Neil's comment
> about static variables.
>
> Meanwhile, I'd also like to hear your opinions about symbol separation
> approach itself.

I have one concern, which Devang and I have discussed offline.  
Basically,
the question is about the symbol separation model: do we expect that 
there
will be lots and lots of repositories, and that a user might include 
dozens of
them in a single translation unit, or do we expect that each 
compilation will
only use one or two repositories?

My guess is that we should expect the latter.  If so, then I think we 
ought to
have a different interface: instead of having the preprocessor look for 
a
.cfinfo every time it finds a .h, we should have the compiler use only 
the
.cfinfo files that are explicitly passed to it as command line 
arguments.

Rationale: compilation speed.  A single compilation may very easily 
include
hundreds of .h files.  This is especially true of the kinds of code we 
compile
at Apple, where we tend to use enormous framework headers, but I think
we've all seen examples of this on lots of systems.  Having the compiler
look for a .cfinfo file whenever it sees a .h file can take a great 
deal of time.
(This isn't speculation, by the way.  We've seen a 3% slowdown here at
Apple.)  If we're looking for hundreds of .cfinfo files and only 
finding one,
then that time is wasted; we should just tell the compiler where to 
find that
one .cfinfo file, instead of making it discover the location for itself.

			--Matt