Re: (patch) hpjyg09: bcache optimizations

[Jimmy Guo <guo at cup dot hp dot com>]

Given Jim Blandy's comments:
  http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00188.html

and Srikanth's clarification:
  http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00190.html

I think we should look at the issue of bypassing and the issue of bcache
hash implementation separately.

Bcache is introduced to deal with duplicate symbols.  Where it is not
necessary, it just adds time and space overheads, and that could be
significant for HP customers debugging large applications.  The tuning
of bcache hash is probably necessary, but that's a general and separate
issue.

I'd like to tackle the bypass scheme initially to introduce an
acceptable bypass mechanism which gives gdb users with platform compiler
combintations like HP-UX + HP cc compiler a faster / smaller footprint
gdb for large apps -- 
    Controlling the bypass through a target dependent macro def is out.
    The bcache_ignore_duplicates() and bcache_filter_duplicates() calls
    still need to be added, and be used to bypass bcache when detecting
    that the HP compiler is used (and if gcc is used, gdb will still use
    bcache).
Comments?

As to the macro implementation of hash(), that is a smaller issue and
will be looked at with some more performance benchmarking to answer
whether or not "Inlining such a relatively large body of code is
definitely not a definite win".  Again, the focus will be debugging
large applications, as typical for HP customers.

- Jimmy Guo, guo@cup.hp.com