[RFA,1/2] Speed up dict_hash

  On 11/08/2017 06:44 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
>>> For "gdb -nx -readnow -batch gdb", this improves the time from ~9.8s
>>> before to ~8.5s afterward.
> 
> Pedro> Nice!
> 
> I rebuilt today and the baseline times were higher -- now it starts at
> ~14.1s for an unmodified gdb, down to ~12.2 with my patch.  I'm not sure
> if this is due to some other patch, or if the additional time is because
> I configured differently (I enabled guile, python, and all targets in
> this most recent build).  If so, 4 seconds (comparing to the ~10 seconds
> last time around) seems awfully expensive for those features...

I'm seeing a lot of time (24%!) spent in gettext, via complaints...
perf shows:

-   86.23%     0.00%  gdb      gdb                     [.] gdb_main
   - gdb_main
      - 85.60% catch_command_errors
           symbol_file_add_main_adapter
           symbol_file_add_main
           symbol_file_add_main_1
           symbol_file_add
         - symbol_file_add_with_addrs
            - 84.31% dw2_expand_all_symtabs
               - dw2_instantiate_symtab
                  - 83.79% dw2_do_instantiate_symtab
                     - 70.85% process_die
                        - 41.11% dwarf_decode_macros
                           - 41.09% dwarf_decode_macro_bytes
                              - 39.74% dwarf_decode_macro_bytes
                                 + 24.75% __dcigettext
                                 + 7.37% macro_define_object_internal
                                 + 3.16% macro_define_function
                                   0.77% splay_tree_insert
                                 + 0.76% savestring
                                 + 0.58% free
                                   0.53% read_indirect_string_at_offset_from
                                0.54% macro_define_object_internal
                                0.51% macro_start_file
                        + 25.57% process_die
                        + 4.07% dwarf_decode_lines
                     + 4.28% compute_delayed_physnames
                     + 3.85% end_symtab_from_static_block
                     + 3.38% load_cu
                     + 1.29% end_symtab_get_static_block
                  + 0.52% do_my_cleanups
            + 1.29% read_symbols
      + 0.54% gdb_init

Maybe you were building with --disable-intl before?

The problem is that we're computing the arguments to
pass to complaint, including passing the format strings
through gettext, even when complaints are disabled...  

The patch below, improves "gdb -nx -readnow -batch gdb"
from ~11.s to ~7.8s, for me (gcc 5.3.1, -O2, x86_64).

From c171f5097e05fa25553d92b9f9d14bf46207edc2 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Wed, 8 Nov 2017 21:03:15 +0000
Subject: [PATCH] complaints

---
 gdb/complaints.c |  4 ++--
 gdb/complaints.h | 17 ++++++++++++++---
 2 files changed, 16 insertions(+), 5 deletions(-)
  

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I'm seeing a lot of time (24%!) spent in gettext, via complaints...

Hmm, that sounds familiar somehow.

Pedro> Maybe you were building with --disable-intl before?

Not intentionally but perhaps I was missing a dependency.

Pedro> The patch below, improves "gdb -nx -readnow -batch gdb"
Pedro> from ~11.s to ~7.8s, for me (gcc 5.3.1, -O2, x86_64).

Seems like a good idea.  -readnow isn't really used, of course, but I
use it as a simpler-to-measure proxy for CU expansion time, which does
matter occasionally.

Tom
  

On 11/08/2017 11:01 PM, Tom Tromey wrote:

> Pedro> The patch below, improves "gdb -nx -readnow -batch gdb"
> Pedro> from ~11.s to ~7.8s, for me (gcc 5.3.1, -O2, x86_64).
> 
> Seems like a good idea.  -readnow isn't really used, of course, but I
> use it as a simpler-to-measure proxy for CU expansion time, which does
> matter occasionally.

Right.  Alright, I cleaned it up a bit, ran the testsuite,
fixed gdb.gdb/complaints.exp, and pushed it in now:
 https://sourceware.org/ml/gdb-patches/2017-11/msg00197.html

Thanks,
Pedro Alves