Re: Two observations using GDB 13 snapshot

Simon Marchi via Gdb-patches
2022-12-23T03:34:24Z

On 12/19/22 22:26, Eli Zaretskii via Gdb-patches wrote:
>> From: Tom Tromey <tom@tromey.com>
>> Cc: Luis Machado <luis.machado@arm.com>, Tom Tromey <tom@tromey.com>, Eli
>> Zaretskii <eliz@gnu.org>
>> Date: Mon, 19 Dec 2022 14:18:52 -0700
>>
>>>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
>>
>> Eli> Tom, could you please chime in? What could explain such a slowdown
>> Eli> using -readnow and in the MinGW build without worker threads (since
>> Eli> GDB 12 didn't use threads, either)? And why -readnow is so different
>> Eli> from a GDB built without threading?
>>
>> Just a quick answer for now, I haven't tried to reproduce or
>> investigate...
>>
>> -readnow should not really be affected by the DWARF scanner rewrite.
>> With -readnow, all the new code is bypassed anyway. For quite a while
>> now, -readnow (when using DWARF anyway) has operated on the principle
>> that since gdb is reading full symbols, it might as well not bother with
>> partial symbols (or now, the index).
>>
>> Threads also should not matter here, because only the initial scan can
>> use multiple threads. The full symbol reader is single-threaded and
>> hasn't changed in any deep way since GDB 12.
>>
>> It's possible that some other change affected this -- the DWARF reader
>> in general sees a lot of patches. I don't know which one it might be
>> offhand, though.
>
> So you are saying that the rewrite of the DWARF scanner could be the
> reason for the slowness?
>
> Let me know if I can provide any additional information that could be
> useful in investigating this.

Just wondering, do you build with or without optimizations?

Simon