Re: Two observations using GDB 13 snapshot

[Eli Zaretskii <eliz@gnu.org>]

> 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.

Would it be useful to open a bugzilla issue?