Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Dmitry Antipov <dantipov@nvidia.com>
To: Pedro Alves <palves@redhat.com>
Cc: <gdb@sourceware.org>
Subject: Re: Note on choosing string hash functions
Date: Tue, 28 Nov 2017 15:13:00 -0000	[thread overview]
Message-ID: <05be76c3-56ff-36bf-ec57-e1339684381d@nvidia.com> (raw)
In-Reply-To: <2ae7734e-3ea1-e017-4a87-65a3af25d0c0@redhat.com>

On 11/28/2017 03:00 PM, Pedro Alves wrote:

> Anyway, this is just a brain dump from a little investigation I did this past
> weekend, and I think that this area has a lot of scope for improvements, but
> I won't be able to follow up on any of this myself in the next following
> weeks at least, with several gdb 8.1 issues on my platе.

Just for the record, I have a brain dump around this area too :-). Instead of
optimizing htab_hash_string itself, we can try to reduce number of calls (and
drop a few calls to strcmp as well if lucky):

---
  gdb/symtab.c | 10 ++++++++--
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gdb/symtab.c b/gdb/symtab.c
index ebb7fbe1e0..c9dab4d575 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -673,6 +673,7 @@ symbol_set_language (struct general_symbol_info *gsymbol,
  struct demangled_name_entry
  {
    const char *mangled;
+  hashval_t hashval;
    char demangled[1];
  };

@@ -684,7 +685,7 @@ hash_demangled_name_entry (const void *data)
    const struct demangled_name_entry *e
      = (const struct demangled_name_entry *) data;

-  return htab_hash_string (e->mangled);
+  return e->hashval;
  }

  /* Equality function for the demangled name hash.  */
@@ -697,7 +698,8 @@ eq_demangled_name_entry (const void *a, const void *b)
    const struct demangled_name_entry *db
      = (const struct demangled_name_entry *) b;

-  return strcmp (da->mangled, db->mangled) == 0;
+  return (da->hashval != db->hashval) ? 0
+    : (strcmp (da->mangled, db->mangled) == 0);
  }

  /* Create the hash table used for demangled names.  Each hash entry is
@@ -816,6 +818,8 @@ symbol_set_names (struct general_symbol_info *gsymbol,
      linkage_name_copy = linkage_name;

    entry.mangled = linkage_name_copy;
+  entry.hashval = htab_hash_string (linkage_name_copy);
+
    slot = ((struct demangled_name_entry **)
           htab_find_slot (per_bfd->demangled_names_hash,
                           &entry, INSERT));
@@ -848,6 +852,7 @@ symbol_set_names (struct general_symbol_info *gsymbol,
                               offsetof (struct demangled_name_entry, demangled)
                               + demangled_len + 1));
           (*slot)->mangled = linkage_name;
+         (*slot)->hashval = entry.hashval;
         }
        else
         {
@@ -864,6 +869,7 @@ symbol_set_names (struct general_symbol_info *gsymbol,
           mangled_ptr = &((*slot)->demangled[demangled_len + 1]);
           strcpy (mangled_ptr, linkage_name_copy);
           (*slot)->mangled = mangled_ptr;
+         (*slot)->hashval = entry.hashval;
         }

        if (demangled_name != NULL)
-- 

This immediately moves htab_hash_string down in reports, from:

      9.67%  gdb      gdb                       [.] find_pc_sect_psymtab
      6.62%  gdb      gdb                       [.] bcache_full
      5.41%  gdb      libc-2.25.so              [.] tolower
      4.44%  gdb      gdb                       [.] htab_hash_string                    ; 4th place
      4.14%  gdb      gdb                       [.] htab_find_slot_with_hash
      3.86%  gdb      gdb                       [.] load_partial_dies
      3.56%  gdb      gdb                       [.] strcmp_iw_ordered
      3.48%  gdb      gdb                       [.] read_indirect_string_at_offset_from
      3.26%  gdb      gdb                       [.] lookup_minimal_symbol_by_pc_name
      3.12%  gdb      gdb                       [.] cpname_parse
      2.77%  gdb      gdb                       [.] read_attribute_value
      2.72%  gdb      gdb                       [.] cpname_lex
      2.71%  gdb      libc-2.25.so              [.] __strcmp_sse2_unaligned
      2.49%  gdb      gdb                       [.] peek_die_abbrev
      2.30%  gdb      libc-2.25.so              [.] _int_malloc
      2.16%  gdb      gdb                       [.] d_print_comp_inner

to:

      9.78%  gdb      gdb                       [.] find_pc_sect_psymtab
      6.63%  gdb      gdb                       [.] bcache_full
      5.00%  gdb      libc-2.25.so              [.] tolower
      4.20%  gdb      gdb                       [.] htab_find_slot_with_hash
      3.79%  gdb      gdb                       [.] load_partial_dies
      3.68%  gdb      gdb                       [.] lookup_minimal_symbol_by_pc_name
      3.54%  gdb      gdb                       [.] read_indirect_string_at_offset_from
      3.47%  gdb      gdb                       [.] strcmp_iw_ordered
      3.39%  gdb      gdb                       [.] cpname_parse
      2.71%  gdb      gdb                       [.] read_attribute_value
      2.53%  gdb      gdb                       [.] cpname_lex
      2.46%  gdb      gdb                       [.] peek_die_abbrev
      2.43%  gdb      gdb                       [.] d_print_comp_inner
      2.43%  gdb      libc-2.25.so              [.] _int_malloc
      2.38%  gdb      gdb                       [.] htab_hash_string                    ; 15th place

at the cost of having per_bfd->storage_obstack ~3.7% larger for libxul.so with ~2.3M symbols.

Dmitry


  reply	other threads:[~2017-11-28 15:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17  9:50 Dmitry Antipov
2017-11-17 13:42 ` Pedro Alves
2017-11-22  2:10   ` Pedro Alves
2017-11-22  2:25     ` Pedro Alves
2017-11-28 10:35     ` Dmitry Antipov
2017-11-28 12:00       ` Pedro Alves
2017-11-28 15:13         ` Dmitry Antipov [this message]
2017-11-28 15:23           ` Pedro Alves

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=05be76c3-56ff-36bf-ec57-e1339684381d@nvidia.com \
    --to=dantipov@nvidia.com \
    --cc=gdb@sourceware.org \
    --cc=palves@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