[Bug symtab/16994] New: performance issue looking up static symbols (e.g. int, int64 typedef).

[Bug symtab/16994] New: performance issue looking up static symbols (e.g. int, int64 typedef).

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16994

            Bug ID: 16994
           Summary: performance issue looking up static symbols (e.g. int,
                    int64 typedef).
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

This pr is to address the performance issue gdb has when looking up symbols in
STATIC_BLOCK.

gdb will iterate over all CUs looking for static symbols as a last resort, but
this introduces performance issues that one might not easily predict.
See pr 16253 for an example of accidentally introducing such a perf regression.

E.g., to perform "info fun ^foo::(anonymous namespace)", inspect_type will
first look in STRUCT_DOMAIN for a symbol, and if that fails look in VAR_DOMAIN.
 However, the attributes in .gdb_index don't distinguish STRUCT_DOMAIN types
from VAR_DOMAIN types.  During symbol lookup, dw2_symtab_iter_next will return
every entry that exists for int64 (and there can be thousands), gdb will expand
the CU, look for the symbol, not get a match because it's in the wrong domain,
and then try the next.
This will cause gdb to expand every CU.  Then when this lookup fails
inspect_type will try VAR_DOMAIN, assuming the user was willing to wait that
long ...

In this case the "last resort" lookup is killing us, we want the lookup in
STRUCT_DOMAIN to fail fast.

ref: symtab.c:lookup_symbol_aux
    /* Now search all static file-level symbols.  Not strictly correct,         
       but more useful than an error.  */

  =>return lookup_static_symbol_aux (name, domain);

"more useful than an error" is ignoring the *massive* performance hit (and by
massive I mean effectively doing a -readnow in a program with a 2G fission .dwp
file).

There is also the issue of looking up base types like "int". It can be slower
than necessary too, for similar reasons.  Plus if some type isn't defined in
the CU (say double) then we want gdb to look in the default set (provided by
the architecture) after it has looked in the current CU and before it does this
last
resort attempt of looking through all CUs.  One reason for doing this is that
if the next CU to be looked in happened to be compiled with -fshort-double gdb
will give the wrong answer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16994] performance issue looking up static symbols (e.g. int, int64 typedef).

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16994

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |performance

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16994] performance issue looking up static symbols (e.g. int, int64 typedef).

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16994

--- Comment #1 from dje at google dot com ---
In the .gdb_index of the monster benchmark I'm using, there are 10K entries for
int64, and none for void.
Thus any time gdb iterates over symbol tables to look up void, it's a total
waste of time.

gdb should probably (still TBD) use .gdb_index for STATIC_BLOCK lookups in
addition to GLOBAL_BLOCK lookups (see pr 16998), before iterating over all
currently expanded symtabs.  But I think the case of looking up "void" is a
good example of needing to look in the default set (provided by the arch) after
looking in the current CU for STATIC_BLOCK lookups.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/16994] performance issue looking up static symbols (e.g. int, int64 typedef).

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16994

Doug Evans <xdje42 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xdje42 at gmail dot com

--- Comment #2 from Doug Evans <xdje42 at gmail dot com> ---
Filed PR 17684 to address the particular case of looking up builtin(/primitive)
types.

-- 
You are receiving this mail because:
You are on the CC list for the bug.