Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Feb 17, 2004 at 07:38:55PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > On Tue, Feb 17, 2004 at 02:09:49PM -0500, Elena Zannoni wrote:
>  > > Daniel Jacobowitz writes:
>  > >  > Because the cleaner interface is not my goal - it's a side goal to my
>  > >  > actual aims, which are improved GDB startup time and memory usage. 
>  > > 
>  > > >From your previous postings I understand is that your cplusplus stuff
>  > > has a noticeable impact on performance and memory usage and you are
>  > > trying to shave gdb's time and size wherever there is a chance. From
>  > > Paul's postings instead I get the impression that he needs to revise
>  > > the current interface.
>  > 
>  > This has, in fact, nothing to do with the C++ stuff.  This has to do
>  > with the fact that when I start GDB on a 200MHz board with debug info
>  > in glibc, it takes more than thirty seconds to load partial symbol
>  > tables.  That's so slow as to be unusable.  It makes the entire
>  > testsuite timeout, for one thing.
>  > 
> 
> Did you identify specific bottlenecks?

Yes, and this is aimed at the first of them.  From my mail yesterday:

  This whole project grew out of profiling results for a large dwarf2 C
  application, which shows a similar profile to C++ : the biggest hot
  spot in startup time today is compare_psymbols.  My hope is to do that
  using strcmp, or something even more efficient, instead of ~6,000,000
  calls to strcmp_iw.  I started working on the symbol name cleanups
  first, but I think saving the hash code in the symbol_name_info might
  be even more effective.

I don't have all my numbers handy any more, but here's a profile
(gprof-based) for loading gdb with debug info in gdb.  I verified with
oprofile that the effect is real - strcmp_iw_ordered fell to about 27%
which leaves it still dominating.  First column is percentage of total
time for the "file" command.

 36.36     10.52    10.52  3279588     0.00     0.00  strcmp_iw_ordered
  9.44     13.25     2.73   510855     0.00     0.00  bcache_data
  7.45     15.40     2.15   526225     0.00     0.00  hash
  6.48     17.28     1.88                             htab_find_slot_with_hash

I realize this explanation was short on details.  My hope was that by
shrinking the amount of data (full demangled names are more complex
than non-params names, although we still have to contend with template
arguments) I could make it practical to canonicalize these before
storing them.  Then we could canonicalize user input that we want to
look up, and use strcmp instead of strcmp_iw_ordered to sort; I'm
estimating that strcmp is in the 10x-20x faster range although
benchmarking it is still on my TODO.  But I have a pretty good idea of
how long strcmp takes on this amount of data, and we're off the scale.

I'm no longer convinced that canonicalizing was a good idea.  It may be
better to:
 - adapt msymbol_hash_iw, and sort the psymbols by a stored hash value.
   The scheme I described, with a shared struct containing name
   pointers, recovers most of the space and time cost of this.
 - or hash the psymbols, which will require substantial changes to
   the very few places that want to search all psymbols, and I don't
   know how to make this work properly with the (very important)
   psymbol bcache.
 - or something else entirely.

>  > As for the interface, I don't think that the cleanup patches I've
>  > posted so far have any substantial effect on the interface.  I was not
>  > planning to post that existing grossness, my weekend hack, as a
>  > proposal - it was an answer to "can you elaborate".  Before submitting
>  > patches to implement it I would, I would hope, have asked for comments
>  > on the interface.  But if I can't make the interface go faster, then
>  > there's no point in proposing the interface.  That is a work in
>  > progress.
>  > 
> 
> I had to pry this info out of you over a few e-mail exchanges. Your
> first posting didn't explain what you were doing, just that you were
> testing some new approach. Since the patch seemed to be put together
> in a hurry (and that's why I asked you to split it) I honestly wanted
> to know what you were planning to do, especially since you are adding
> a new macro. So it seemed to me that you were doing exactly that: going
> ahead with the first stages of a big change but that the change itself
> hadn't been discussed.

The patch was not in one piece because I was in a hurry.  It was in one
piece because I honestly thought it made _more_ sense that way, as a
group of related changes.  I get it hammered into me every couple of
months that other GDB developers have a different opinion of reasonable
patch units than I do.  I would not have submitted it if I didn't think
it was worthwhile completely independent of whatever I was hacking on
in another tree.

As soon as you asked where I was going I answered, in detail.

>  > You want a high level big picture?  I would like to separate the
>  > concepts of full demangled name for language-specific use and
>  > minimalist demangled data (basename, non-DMGL_PARAMS, whatever else)
>  > needed for lookups in the symbol table.  This lets us reduce the
>  > storage used by the symbol table, the data we have to generate at
>  > startup, and the data we have to wade through when lookup things up in
>  > the tables.
>  > 
> 
> thank you.  What do you mean by separate? Where would you store the
> demangled name? Have it demangled on demand only?

See my previous response:
  http://sources.redhat.com/ml/gdb-patches/2004-02/msg00447.html

Yes, SYMBOL_DEMANGLED_NAME would fill in the demangled name on demand. 
This is something we did, as far as I know, "once upon a time" - but
because we didn't have the concept of separate demangled names and
search names that I'm experimenting with, and because we didn't cache
the demangled names, and because the demangler was much slower, the
runtime cost was prohibitive.  I think that now it won't be.

Hmm, the idea of using the hash as a sorting key has potential.  I need
to experiment with that.  It will take back most of the memory savings
I currently have, but it should cut most of that 30% off my profile.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer