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