This is the mail archive of the gdb@sourceware.org mailing list for the GDB 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: Note on choosing string hash functions


On 11/22/2017 05:10 AM, Pedro Alves wrote:

I observe between 3% / 10% time drop.

(I used Joel's version of --readnever from here:
  https://sourceware.org/ml/gdb-patches/2016-07/msg00103.html)

So in sum, I'm pretty convinced the patch is safe as is.

BTW, shouldn't we use safe-ctype.h macros through gdb/utils.c as well?
With this, there is a substantial difference between:

     9.83%  gdb      gdb                       [.] find_pc_sect_psymtab
     6.54%  gdb      gdb                       [.] bcache_full
     5.38%  gdb      libc-2.25.so              [.] tolower                             ; hmm...
     4.48%  gdb      gdb                       [.] htab_find_slot_with_hash
     4.39%  gdb      gdb                       [.] htab_hash_string
     3.88%  gdb      gdb                       [.] load_partial_dies
     3.61%  gdb      gdb                       [.] strcmp_iw_ordered
     3.45%  gdb      gdb                       [.] read_indirect_string_at_offset_from
     3.18%  gdb      gdb                       [.] cpname_parse
     3.07%  gdb      gdb                       [.] lookup_minimal_symbol_by_pc_name
     2.70%  gdb      gdb                       [.] read_attribute_value
     2.68%  gdb      libc-2.25.so              [.] __strcmp_sse2_unaligned
     2.47%  gdb      gdb                       [.] cpname_lex
     2.44%  gdb      gdb                       [.] peek_die_abbrev
     2.32%  gdb      libc-2.25.so              [.] _int_malloc
     2.15%  gdb      gdb                       [.] d_print_comp_inner
     1.80%  gdb      libc-2.25.so              [.] isspace                             ; hmm...
     1.47%  gdb      gdb                       [.] cp_canonicalize_string[abi:cxx11]
     1.45%  gdb      gdb                       [.] eq_demangled_name_entry
     1.39%  gdb      libc-2.25.so              [.] malloc_consolidate.part.1

and:

    10.97%  gdb      gdb                       [.] find_pc_sect_psymtab
     7.25%  gdb      gdb                       [.] bcache_full
     4.82%  gdb      gdb                       [.] htab_hash_string
     4.65%  gdb      gdb                       [.] htab_find_slot_with_hash
     4.28%  gdb      gdb                       [.] load_partial_dies
     3.69%  gdb      gdb                       [.] read_indirect_string_at_offset_from
     3.45%  gdb      gdb                       [.] cpname_parse
     3.37%  gdb      gdb                       [.] lookup_minimal_symbol_by_pc_name
     3.03%  gdb      gdb                       [.] read_attribute_value
     3.01%  gdb      gdb                       [.] strcmp_iw_ordered
     2.99%  gdb      libc-2.25.so              [.] __strcmp_sse2_unaligned
     2.81%  gdb      gdb                       [.] peek_die_abbrev
     2.74%  gdb      gdb                       [.] cpname_lex
     2.57%  gdb      libc-2.25.so              [.] _int_malloc
     2.40%  gdb      gdb                       [.] d_print_comp_inner
     1.59%  gdb      gdb                       [.] eq_demangled_name_entry
     1.56%  gdb      libc-2.25.so              [.] malloc_consolidate.part.1
     1.56%  gdb      gdb                       [.] cp_canonicalize_string[abi:cxx11]
     1.00%  gdb      libc-2.25.so              [.] strlen

IIUC this is because strcmp_iw_ordered() is quite critical when building partial symbol tables.

Dmitry


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