This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Improving gcc scalability wrt _extra_ large C files


Jacques THOMAS <jthomas at cs dot purdue dot edu> writes:

[...]

| My idea for improving lookup_tag is to use one hash table per binding
| level, with entries pointing to the tags of the binding level. To do
| that I would modify push_tag so that it does insert the symbol in the
| hash table at the same time that it does insert it in the linked
| list. lookup_tag could then use this hash table to do faster lookups.

Funny enought, this is exactly the kind of work I'm currently doing.
Somes notes about my work

  1) I have deleted the two notions of binding-level and scope.
     They are replaced with the single notion of "scope" as per the
     C++ standard definition.

  2) I'm using indeed a hash table to implement name lookup.  To make
     this efficient, I've augmented struct ht_identifier with a new
     filed "hash_value" that caches the hash value computed by 
     hashtable.c:calc_hash()

However, what I've seen so far is that this results into a large
amount of code being touched or restructrured.  I'll post a patch
mainline once I've resolved a couple of regressions, then I hope we
will see which parts can be safely backported to 3.3

At any rate, your analysis matches mine on the issue that GCC/g++ is
spending an excessive amount of time in name lookup.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]