From: Elena Zannoni <ezannoni@cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>,
Daniel Jacobowitz <drow@mvista.com>,
gdb-patches@sources.redhat.com
Subject: Re: [rfa] symbol hashing, part 1/n - updates to hash functions
Date: Fri, 12 Oct 2001 08:54:00 -0000 [thread overview]
Message-ID: <15303.5067.139158.779831@krustylu.cygnus.com> (raw)
In-Reply-To: <B987FF9E-BEA3-11D5-A4DE-0030657B5340@cgsoftware.com>
Daniel Berlin writes:
>
> On Thursday, October 11, 2001, at 07:58 PM, Elena Zannoni wrote:
>
> > Daniel Jacobowitz writes:
> >> This patch still has two logical parts; if you strongly prefer I can
> >> break
> >> it up further, but they are somewhat intertwined and I think neither
> >> should
> >> be objectionable. They are:
> >> - Fix a looping bug in msymbol_hash_iw. It would not stop on '(' if
> >> there
> >> was whitespace before it.
> >> - Update to use the identifier hash function that libiberty uses, and
> >> more buckets.
> >>
> >> Is this OK?
> >
> > Looks ok to me in theory. Except that, why was the
> >
> > '% MINIMAL_SYMBOL_HASH_SIZE;'
> >
> > bit moved outside of the msymbol_hash and msymbol_hash_iw functions?
> So msymbol_hash and hash_iw could be used elsewhere.
I see, can we leave the "% MINIMAL_SYMBOL_HASH_SIZE;" where it was
then, until we get to the next patch?
>
> > You still do the same operation with the results returned by the two
> > functions anyway.
> >
> Except, now they are just hash functions, not hash functions that only
> work for the minsym hash tables.
>
Right, OK.
> > Also, where are these 2 functions used besides mynsyms.c?
> In a further symbol hashing patch, unless he changed it.
>
All right. Then the changes to the '%' thing should be put in the
future patch.
> > I think we
> > should make them static and remove the extern from symtab.h.
> >
>
> > Can you give me an example where the '(' error comes up? (Just so I
> > understand it better). How did you come up with the number of
> > buckets?
>
> Averaging based on a large number of gnome, kde, and other real
> applications (ie emacs), compiled with debug info.
> 349 is way too small, we ended up with chains > length 100, all the time.
>
OK.
> > Is this also used in libiberty?
>
> Which, the hash function?
> > Can you fix it and resubmit?
> >
Never mind, I meant the number of buckets. But you answered that.
Elena
next prev parent reply other threads:[~2001-10-12 8:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 7:57 Daniel Jacobowitz
2001-10-11 16:51 ` Elena Zannoni
2001-10-11 16:58 ` Daniel Berlin
2001-10-12 8:54 ` Elena Zannoni [this message]
2001-10-11 17:01 ` Daniel Jacobowitz
2001-10-12 8:59 ` Elena Zannoni
2001-10-12 12:09 ` Daniel Jacobowitz
2001-10-12 15:34 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15303.5067.139158.779831@krustylu.cygnus.com \
--to=ezannoni@cygnus.com \
--cc=dan@cgsoftware.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox