Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?

On Wed, May 22, 2013 at 9:41 PM, Paul Smith <[email protected]> wrote:
> On Wed, 2013-05-22 at 19:44 -0700, Doug Evans wrote:
>> On Wed, May 22, 2013 at 4:14 PM, Paul Smith <[email protected]> wrote:
>> > On Wed, 2013-05-22 at 14:12 -0600, Tom Tromey wrote:
>> > And the top 10 users in the slow instance:
>> >
>> > Each sample counts as 0.01 seconds.
>> >   %   cumulative   self               self     total
>> >  time   seconds   seconds    calls   ms/call  ms/call  name
>> >  23.99     14.26    14.26 69374700      0.00     0.00  lookup_partial_symbol
>> >  23.77     28.39    14.13 784950557     0.00     0.00  strcmp_iw
>> >  11.74     35.37     6.98 763482775     0.00     0.00  symbol_get_demangled_name
>> >   7.23     39.67     4.30 819480663     0.00     0.00  symbol_natural_name
>> >   7.22     43.96     4.29   373483      0.01     0.01  lookup_symbol_aux_psymtabs
>> >   5.60     47.29     3.33 777569558     0.00     0.00  symbol_matches_domain
>> >   4.98     50.25     2.96 819477261     0.00     0.00  symbol_search_name
>> >   2.46     51.71     1.46 34366788      0.00     0.00  strcmp_iw_ordered
>> >   1.51     52.61     0.90        4    225.00   225.00  fprintf_symbol_filtered
>> >   1.46     53.48     0.87 15316453      0.00     0.00  xstrdup
>>
>> Looks rather familiar.  :-)
>
> Hi Doug; I'm not sure what that means; is there already a bug filed
> about this?  Is it a known issue?
>
> I tested with the latest code on master in the Git repo earlier today
> and saw the same slow behavior, so it's not been fixed since 7.6 was
> released.

Hi.
That was more an off-the-cuff comment as I've done a ton of profiling
and reading of gdb's symbol table code (one can only do it in stages -
it can get quite depressing).
And I can't offhand explain why you *only* see the slowdown with a
core file and not with a live executable.

I wasn't aware of the problems with the 12/11/16 patch you found.
I've submitted a minor improvement - IMO the real fix will involve a
lot more effort - gdb's symbol handling is obtuse enough that it's
easy to introduce performance regressions or even overlook basic
performance problems.