public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Project Archer <archer@sourceware.org>
Subject: Re: gcc dwarf2out: Drop the size + performance overhead of DW_AT_sibling
Date: Wed, 19 Oct 2011 09:34:00 -0000	[thread overview]
Message-ID: <1319016858.8669.81.camel@springer.wildebeest.org> (raw)
In-Reply-To: <20111018094457.GB2412@host1.jankratochvil.net>

Hi Jan,

On Tue, 2011-10-18 at 11:44 +0200, Jan Kratochvil wrote:
> On Tue, 18 Oct 2011 11:26:03 +0200, Mark Wielaard wrote:
> > On Mon, 2011-10-17 at 15:36 +0200, Jan Kratochvil wrote:
> > > gcc.post: 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
> 	http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00992.html
> 
> 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:
> 	http://people.redhat.com/jkratoch/ns.tar.xz

Thanks for those. Some quick benchmarks show systemtap selection of
functions and function parameters is slightly slower without
DW_AT_sibling being available. But not dramatically.

$ for i in $(find ns -name libstdc++.so.6.0.17.debug); do echo $i; time
stap -l "process(\"$i\").function(\"*\")" | wc --lines; done
ns/gccgit-c-xxxxxxxxxxxxx-test/default/libstdc++.so.6.0.17.debug
1852

real	0m0.427s
user	0m0.392s
sys	0m0.036s
ns/gccgit-c-xxxxxxxxxxxxx-test/gdbindex/libstdc++.so.6.0.17.debug
1852

real	0m0.422s
user	0m0.384s
sys	0m0.035s
ns/gccgit-c-ns-xxxxxxxxxx-test/default/libstdc++.so.6.0.17.debug
1852

real	0m0.447s
user	0m0.406s
sys	0m0.042s
ns/gccgit-c-ns-xxxxxxxxxx-test/gdbindex/libstdc++.so.6.0.17.debug
1852

real	0m0.443s
user	0m0.404s
sys	0m0.037s

That is selecting all functions in libstdc++. Systemtap doesn't use
gdbindex, but I included it so you can see the "noise". Here the
slowdown seems somewhat equal to the noise.

If we also want parameters/variables listed for each function probe
point (using -L) things are a bit more visible:

$ for i in $(find ns -name libstdc++.so.6.0.17.debug); do echo $i; time
stap -L "process(\"$i\").function(\"*\")" | wc --lines; done
ns/gccgit-c-xxxxxxxxxxxxx-test/default/libstdc++.so.6.0.17.debug
1852

real	0m0.573s
user	0m0.522s
sys	0m0.043s
ns/gccgit-c-xxxxxxxxxxxxx-test/gdbindex/libstdc++.so.6.0.17.debug
1852

real	0m0.558s
user	0m0.505s
sys	0m0.052s
ns/gccgit-c-ns-xxxxxxxxxx-test/default/libstdc++.so.6.0.17.debug
1852

real	0m0.611s
user	0m0.556s
sys	0m0.056s
ns/gccgit-c-ns-xxxxxxxxxx-test/gdbindex/libstdc++.so.6.0.17.debug
1852

real	0m0.603s
user	0m0.557s
sys	0m0.045s

Still no dramatic slowdown, but probably enough to discount random noise
in the measurements.

So DW_AT_sibling definitely does help systemtap/libdw walk a little bit
more efficient through the DIE tree. But you are right that walking the
DIE tree even without them can be done pretty quickly.

Cheers,

Mark

  parent reply	other threads:[~2011-10-19  9:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201110170508.p9H581vh028090@shell.devel.redhat.com>
     [not found] ` <20111017133634.GA5677@host1.jankratochvil.net>
     [not found]   ` <1318929963.8669.2.camel@springer.wildebeest.org>
2011-10-18  9:45     ` Jan Kratochvil
2011-10-18  9:49       ` Jan Kratochvil
2011-10-19  9:34       ` Mark Wielaard [this message]
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:
  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=1319016858.8669.81.camel@springer.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=archer@sourceware.org \
    --cc=jan.kratochvil@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).