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