public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/87432] LTO produced debug info makes gdb slow
[not found] <bug-87432-4@http.gcc.gnu.org/bugzilla/>
@ 2022-04-19 20:52 ` tromey at gcc dot gnu.org
0 siblings, 0 replies; only message in thread
From: tromey at gcc dot gnu.org @ 2022-04-19 20:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432
Tom Tromey <tromey at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at gcc dot gnu.org
--- Comment #2 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #0)
> For example starting gdb on LTO bootstrapped cc1 takes s and ~1.8GB memory
> for me. Setting a breakpoint on do_rpo_vn takes another 3s. That feels a
> lot slower than doing this on a non-LTO bootstrapped cc1.
>
> This bug is to track what _GCC_ can do better here.
Note that in gdb, those are two different code paths.
We recently rewrote the initial scan to be much faster (10x improvement
isn't uncommon). This affects the startup time.
However, setting a breakpoint currently requires a full CU expansion.
That's still probably slow. For gdb performance the best thing for
this case is if each CU is reasonably small.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2022-04-19 20:52 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-87432-4@http.gcc.gnu.org/bugzilla/>
2022-04-19 20:52 ` [Bug debug/87432] LTO produced debug info makes gdb slow tromey at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).