Re: Two observations using GDB 13 snapshot

Eli Zaretskii via Gdb-patches
2022-12-20T03:26:31Z

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