[patchv2 2/2] Accelerate lookup_symbol_aux_objfile 14.5x [Re: [patch 0/2] Accelerate symbol lookups 15x]
Jan Kratochvil
jan.kratochvil@redhat.com
Fri Oct 24 07:33:00 GMT 2014
On Fri, 24 Oct 2014 09:16:01 +0200, Doug Evans wrote:
> One thought I have is that significant changes at a higher level will
> minimize the impact of this patch. One change I'm thinking of making
> is replacing iterating over every symbol table and then if that fails
> going to the index with instead just going straight to the index: the
> index knows where the symbols are (you mentioned this as well).
Yes, I tried that first.
For the performance testcase I provided the issue is in
lookup_symbol_global_iterator_cb():
data->result = lookup_symbol_aux_objfile (objfile, GLOBAL_BLOCK,
data->name, data->domain);
if (data->result == NULL)
data->result = lookup_symbol_aux_quick (objfile, GLOBAL_BLOCK,
data->name, data->domain);
Changing their order does not fix the performance as lookup_symbol_aux_quick()
(that is quick_symbol_functions::lookup_symbol) can return NULL
* either if the symbol is really not present in the index.
* or if the symbol's symtab is already expanded.
For the latter case (commonly happening) quick_symbol_functions::lookup_symbol
finds the right symtab but then it drops that information.
Changing the quick_symbol_functions::lookup_symbol semantics may fix it.
But then it will get fixed only for .gdb_index files while my two patches also
improve performance of non-.gdb_index files.
For each objfile .gdb_index presence is orthogonal to DWZ application.
Sure a question remains if we should care about performance of non-.gdb_index
files at all. Even for continuous edit-build-debug cycles it is worth to run
gdb-add-index during each build.
> If we were to go this route (and apologies for the delay), can you
> write a routine like lookup_block_symbol which does the above and call
> that here instead?
OK.
Jan
More information about the Gdb-patches
mailing list