Re: [patchv2 2/2] Accelerate lookup_symbol_aux_objfile 14.5x [Re: [patch 0/2] Accelerate symbol lookups 15x]

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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