Re: [PATCH] Fix method naming bug in new DWARF indexer

[Tom Tromey <tromey@adacore.com>]

Pedro> Hmm, it actually fixes most of the performance for me.  With that
Pedro> new patch (and I guess the linkage names patch made a difference
Pedro> too), I see roughly the same startup time in new gdb vs old gdb
Pedro> when using the same index, and either an index generated by old
Pedro> gdb, or by new gdb.

I'm going to check it in.

Pedro>  [369902] intrusive_list<inferior, intrusive_base_node<inferior> >::begin:
Pedro>           9 [global, function]
Pedro>           255 [global, function]
Pedro> while in the new indexer, for the same function, we have:
[...]

Pedro> What was the logic that the old writer used to come up with the
Pedro> seemingly right number of function entries?

It looks like the old reader checked the value of DW_AT_inline:

-      if (pdi->has_pc_info || pdi->has_range_info
-	  || (!pdi->is_external && pdi->may_be_inlined))
-	{
-	  if (!pdi->is_declaration)
-	    /* Ignore subprogram DIEs that do not have a name, they are
-	       illegal.  Do not emit a complaint at this point, we will
-	       do so when we convert this psymtab into a symtab.  */
-	    if (pdi->name (cu))
-	      add_partial_symbol (pdi, cu);
-	}

and

-	case DW_AT_inline:
-	  {
-	    LONGEST value = attr.constant_value (-1);
-	    if (value == DW_INL_inlined
-		|| value == DW_INL_declared_inlined)
-	      may_be_inlined = 1;
-	  }
-	  break;

Pedro> For the time being, I'll continue using indexes, because as soon
Pedro> as you need to run to a breakpoint from the command line, which I
Pedro> do all the time, then having an index still beats the new
Pedro> scanner.

Yeah :(

What happens here is that gdb does the finalization step in the
background.  Interactively, this helps make it seem faster.  However,
it's not really faster, it is just deferring some work.

You can see it with an invocation like:

   gdb -q -batch -iex 'set debug timestamp 1' -iex 'set debug dwarf-read 1' -ex start ./gdb

Here for gdb-with-an-index I see:

    0.820423 [dwarf-read] dwarf2_initialize_objfile: found gdb index from file
    1.699175 [dwarf-read] process_queue: Expanding one or more symtabs of objfile /tmp/gdb.idx ...

But for ordinary gdb:

    1.310033 [dwarf-read] dwarf2_build_psymtabs_hard: Done building psymtabs of /tmp/gdb
    4.666649 [dwarf-read] process_queue: Expanding one or more symtabs of objfile /tmp/gdb ...

This is disappointing of course.  It might be possible to reduce this
time at the cost of a bit more complexity in the lookup code and perhaps
a bit more memory use.  For example, right now finalization merges the
results from all the readers into a single entry table -- but maybe the
table could remain sharded instead.  Another possibility might be to do
the work in worker threads and, instead of sharding the result, pre-sort
the vectors and use a sorted merge operation to combine them.

I'll file some bugs about these things.
I'm starting to lose track of what I still need to fix up.

Tom