This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patchv2 2/2] Accelerate lookup_symbol_aux_objfile 14.5x [Re: [patch 0/2] Accelerate symbol lookups 15x]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 23 Oct 2014 20:24:34 +0200
- Subject: [patchv2 2/2] Accelerate lookup_symbol_aux_objfile 14.5x [Re: [patch 0/2] Accelerate symbol lookups 15x]
- Authentication-results: sourceware.org; auth=none
- References: <20141020214410 dot GA22011 at host2 dot jankratochvil dot net> <CAP9bCMQ7EXyXJiqK4j2UA9YgxkQiNFFqJPOpbPXH8-YZMRLh2w at mail dot gmail dot com>
On Wed, 22 Oct 2014 10:55:18 +0200, Doug Evans wrote:
> For example, the count of calls to dict_hash before/after goes from 13.8M to 31.
> I'm guessing one t hing we're doing here is coping with an artifact of
> dwz:
During my simple test on non-DWZ file (./gdb itself) it went 3684->3484.
The problem is that dict_cash(val) is called for the same val for each block
(== symtab).
On DWZ the saving is probably much larger as there are many more symtabs due
to DW_TAG_partial_unit ones.
> what was once one global block to represent the entire objfile is
> now N.
Without DWZ there are X global blocks for X primary symtabs for X CUs of
objfile. With DWZ there are X+Y global blocks for X+Y primary symtabs for
X+Y CUs where Y are 'DW_TAG_partial_unit's.
For 'DW_TAG_partial_unit's (Ys) their blockvector is usually empty. But not
always, I have found there typedef symbols, there can IMO be optimized-out
static variables etc.
> [I'm sure the patches help in the non-dwz case, but I suspect it's less.
> Which isn't to say the patches aren't useful.
> I just need play with a few more examples.]
I agree.
[patch 2/2] could needlessly performance-regress non-DWZ cases, therefore
I have put back original ALL_OBJFILE_PRIMARY_SYMTABS (instead of my
ALL_OBJFILE_SYMTABS) as it is perfectly sufficient. For the performance
testcase of mine:
Benchmark on non-trivial application with 'p <tab><tab>':
Command execution time: 4.215000 (cpu), 4.241466 (wall) --- both fixes with new [patch 2/2]
Command execution time: 7.373000 (cpu), 7.395095 (wall) --- both fixes
Command execution time: 13.572000 (cpu), 13.592689 (wall) --- just lookup_symbol_aux_objfile fix
Command execution time: 113.036000 (cpu), 113.067995 (wall) --- FSF GDB HEAD
That is additional 1.75x improvement, making the total improvement 26.8x.
No regressions on {x86_64,x86_64-m32,i686}-fedora21pre-linux-gnu in standard
and .gdb_index-enabled runs. Neither of the patches should cause any visible
behavior change.
Thanks,
Jan
gdb/
2014-10-23 Jan Kratochvil <jan.kratochvil@redhat.com>
* symtab.c (lookup_symbol_aux_objfile): Use ALL_OBJFILE_SYMTABS, inline
lookup_block_symbol.
diff --git a/gdb/symtab.c b/gdb/symtab.c
index c530d50..da13861 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -1657,15 +1657,25 @@ lookup_symbol_aux_objfile (struct objfile *objfile, int block_index,
const struct block *block;
struct symtab *s;
+ gdb_assert (block_index == GLOBAL_BLOCK || block_index == STATIC_BLOCK);
+
ALL_OBJFILE_PRIMARY_SYMTABS (objfile, s)
{
+ struct dict_iterator dict_iter;
+
bv = BLOCKVECTOR (s);
block = BLOCKVECTOR_BLOCK (bv, block_index);
- sym = lookup_block_symbol (block, name, domain);
- if (sym)
+
+ for (sym = dict_iter_name_first (block->dict, name, &dict_iter);
+ sym != NULL;
+ sym = dict_iter_name_next (name, &dict_iter))
{
- block_found = block;
- return fixup_symbol_section (sym, objfile);
+ if (symbol_matches_domain (SYMBOL_LANGUAGE (sym),
+ SYMBOL_DOMAIN (sym), domain))
+ {
+ block_found = block;
+ return fixup_symbol_section (sym, objfile);
+ }
}
}