Re: string pools, final version (committed)

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Zack" == Zack Weinberg <zackw@Stanford.EDU> writes:

    Zack> On Sat, Nov 18, 2000 at 02:14:09PM -0800, Mark Mitchell
    Zack> wrote:
    >> >>>>> "Zack" == Zack Weinberg <zackw@Stanford.EDU> writes:
    >> 
    Zack> affiliated data pointer.  Now what do you do?  Giving both
    Zack> of them their own static slots is not an option; now you've
    Zack> doubled the cost for all hash table entries, and for all
    Zack> front ends whether or not they need it.

    >>  The CPP hash table could then not contain the strings, just
    >> indices/pointers to them.  You still have two different hash
    >> tables -- but only one set of strings.

    Zack> Yes.  I was thinking about this myself, after Richard's
    Zack> suggestion earlier for what to do with
    Zack> TREE_SYMBOL_REFERENCED.  In fact, we could do the same thing
    Zack> for identifier nodes.  I'm not sure that winds up being
    Zack> better, though, considering how most of the string pool
    Zack> entries turn out to be identifiers.

I think my suggestion only makes sense for the CPP identifiers, of
which there are relatively few, assuming I'm understanding how things
work in CPP.  (Macros go in the hash table, but other identifiers
scanned do not?)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com