From: Jim Blandy <jimb@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com, Elena Zannoni <ezannoni@redhat.com>
Subject: Re: [RFA/dwarf] Optimize partial DIE reading for uninteresting DIEs
Date: Thu, 26 Feb 2004 22:28:00 -0000 [thread overview]
Message-ID: <vt21xohlblp.fsf@zenia.home> (raw)
In-Reply-To: <20040225030644.GA5167@nevyn.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> read_partial_die is a pretty heavyweight function. One of the largest
> indicators of this is how high read_uleb128 shows up in startup profiles.
> This patch provides an alternative for DIEs we know are uninteresting: we
> can just read in the abbrev, and the sibling pointer if any.
>
> Performancewise, on mainline this is a bit of a wash for typical code.
> That's because we read every file-scope or namespace-scope DIE using
> read_partial_die before we decide if it's interesting. A followup patch to
> use peek_die_abbrev for that provides a several percent improvement in GDB
> startup time.
Hmm. If I'm reading this right, the only real difference between
calling skip_children and calling locate_pdi_sibling is that the
former calls skip_one_die to get past the attributes, while the latter
calls read_partial_die. Is that right?
skip_one_die:
- stops skipping attributes as soon as it sees a sibling pointer,
- doesn't read the attributes' values, and
- doesn't examine the attributes to fill in a partial_die_info
structure.
But none of that really sounds too expensive, so I'm not surprised
that this change alone is a wash, and I'm curious to see the followup
patch. You haven't posted that yet, right?
It bothers me that the patch would give us two separate form parsers.
It would be nicer if we could just have one function that knows how to
get the proper value of each attribute. Would it be possible for
skip_one_die to call read_attribute, instead of writing out its own
switch? Yes, that would allocate space for the blocks on
dwarf2_tmp_obstack, but I think there are comments in
dwarf2_build_psymtabs_hard explaining that this isn't significant.
For most everything, read_attribute_value just hands out pointers into
the info or string buffer. And you're still not going to be reading
past any sibling attributes, so in the common case you'll never read
much anyway.
next prev parent reply other threads:[~2004-02-26 22:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-25 3:06 Daniel Jacobowitz
2004-02-26 22:28 ` Jim Blandy [this message]
2004-02-26 23:12 ` Daniel Jacobowitz
2004-02-27 2:58 ` Jim Blandy
2004-02-27 3:03 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-09 19:58 ` Daniel Jacobowitz
2004-03-19 0:09 ` Jim Blandy
2004-03-10 14:56 ` Jim Blandy
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=vt21xohlblp.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=drow@false.org \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.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