From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>,
Simon Marchi <simon.marchi@polymtl.ca>
Cc: Tom Tromey <tom@tromey.com>, gdb@sourceware.org
Subject: Re: Multi-threaded dwarf parsing
Date: Wed, 24 Feb 2016 21:10:00 -0000 [thread overview]
Message-ID: <56CE1C56.9010208@redhat.com> (raw)
In-Reply-To: <20160224202519.GA10251@host1.jankratochvil.net>
On 02/24/2016 08:25 PM, Jan Kratochvil wrote:
> On Wed, 24 Feb 2016 17:43:03 +0100, Simon Marchi wrote:
>> instead of blocking on the psymtabs creation at startup
> [...]
>> then the main code will have to block until the corresponding task is
>> complete (dwarf2_require_psymtabs).
>
> If really your concern are psymtabs then use Tom's .gdb_index:
> gdb/contrib/gdb-add-index.sh
I think the index isn't so helpful if the big thing that takes a
while to read/load is what you're changing in a edit/compile/debug
cycle.
Also, that script actually relies on gdb to read the debug info,
intern it, and spit out the index. So if we gdb reads dwarf faster,
then index generation itself becomes faster too.
>
> With .gdb_index GDB still has startup performance problems during full CU
> expansions, that is struct symtab and struct symbol. That happens with C++
> inferiors which have very interlinked CUs and thus expanding one CU means for
> GDB expanding 100+ CUs due to the inter-type dependencies which cannot be left
> opaque in such cases. And as each C++ CU is usually very large...
Sounds like something that could be sped up by reading CUs in parallel.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-02-24 21:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 2:45 Simon Marchi
2016-02-24 11:06 ` Pedro Alves
2016-02-24 15:30 ` Tom Tromey
2016-02-24 16:43 ` Simon Marchi
2016-02-24 19:50 ` Tom Tromey
2016-02-24 20:25 ` Jan Kratochvil
2016-02-24 20:37 ` Simon Marchi
2016-02-24 21:28 ` Jan Kratochvil
2016-02-24 21:10 ` Pedro Alves [this message]
2016-02-24 21:22 ` Jan Kratochvil
2016-02-25 3:31 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CE1C56.9010208@redhat.com \
--to=palves@redhat.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=simon.marchi@polymtl.ca \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox