public inbox for
 help / color / mirror / Atom feed
From: Jan Kratochvil <>
To: Mark Wielaard <>
Cc: Project Archer <>
Subject: gcc dwarf2out: Drop the size + performance overhead of DW_AT_sibling
Date: Tue, 18 Oct 2011 09:45:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Mark,

<warning> moved to a public list </warning>

On Tue, 18 Oct 2011 11:26:03 +0200, Mark Wielaard wrote:
> On Mon, 2011-10-17 at 15:36 +0200, Jan Kratochvil wrote:
> > Drop DW_AT_sibling; remove 27 LoC: -3.49% .debug size, -1.7%
> > GDB time.
> Do you have more information about that? Systemtap for example, which
> uses elfutils libdw uses DW_AT_subling to more efficiently go through
> the debug_info DIEs.

The patch with various benchmarks is:
	[patch] dwarf2out: Drop the size + performance overhead of DW_AT_sibling

GDB also uses DW_AT_sibling when available (skip_one_die and
locate_pdi_sibling).  The mail above quotation:
# I guess DW_AT_sibling had real performance gains on CPUs with 1x (=no) clock
# multipliers.  Nowadays mostly only the data size transferred over FSB matters.

The problem is the DIEs skipping by CPU is so cheap on current CPUs it cannot
be compared with the overhead of providing the helper data for it.  I did not
expect dropping DW_AT_sibling would be even a consumer performance
_improvement_.  I expected more it will be either not measurable or just not
significant enough for the .debug on-disk sizes cost justification.

I did only gdb and idb benchmarks.  systemtap benchmark is welcome, libstdc++
files for benchmark, if it is enough for systemtap this way:


       reply	other threads:[~2011-10-18  9:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
2011-10-18  9:45     ` Jan Kratochvil [this message]
2011-10-18  9:49       ` Jan Kratochvil
2011-10-19  9:34       ` Mark Wielaard
2011-10-19 11:29         ` Jan Kratochvil
2011-10-19 15:38         ` Jan Kratochvil

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).