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

Doug Evans
2013-05-28T17:11:06Z

On Wed, May 22, 2013 at 9:41 PM, Paul Smith <psmith@gnu.org> wrote:
> On Wed, 2013-05-22 at 19:44 -0700, Doug Evans wrote:
>> On Wed, May 22, 2013 at 4:14 PM, Paul Smith <psmith@gnu.org> 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.