Re: Two observations using GDB 13 snapshot

[Luis Machado <luis.machado@arm.com>]

On 12/19/22 12:48, Eli Zaretskii wrote:
>> Date: Mon, 19 Dec 2022 10:07:27 +0000
>> From: Luis Machado <luis.machado@arm.com>
>>
>> On 12/17/22 17:42, Eli Zaretskii via Gdb-patches wrote:
>>> Using the latest snapshot of GDB 13 (MinGW build on native Windows), I
>>> see some strange behavior I've not seen with previous versions:
>>>
>>>     . Very long time to read symbols.  E.g., reading symbols of its own
>>>       binary takes a whopping 2 minutes.  GDB 12.1 does the same in
>>>       under 10 seconds.
>>
>> There used to be a dwarf performance regression, but from looking at the bug (https://sourceware.org/bugzilla/show_bug.cgi?id=29105), it seems to be fixed.
>>
>> I'm not sure if it manifests differently on MinGW.
> 
> This build is without std::thread.  Maybe it's related?

Well, if the worker threads are disabled and things are read by a single thread, that may explain some slowness. But I don't think it would be as slow as you describe.

> 
> Does GDB 13 read DWARF debug info significantly differently than
> previous versions?
> 
> Do you see this on GNU/Linux, when debugging GDB with itself, if you
> disable multithreaded DWARF reading?

For a regular build of GDB 13 (threaded), I see a pretty quick startup (about 3.5 seconds) to start gdb within gdb.

With a GDB 13 built with threading disabled, I see about 15 seconds to do the same.

Now, I noticed -readnow doesn't seem to use the worker threads for reading symbols, so passing that option slow things down significantly, to the point it takes 2 minutes to read the symbols.

I don't know if that's on purpose.

> 
> Thanks.