From: Michael Matz <matz@suse.de>
To: Tom de Vries <tdevries@suse.de>
Cc: dwz@sourceware.org, Jakub Jelinek <jakub@redhat.com>,
Mark Wielaard <mark@klomp.org>
Subject: Re: [RFC] Implement C++ One Definition Rule for struct, class and union
Date: Tue, 01 Jan 2019 00:00:00 -0000 [thread overview]
Message-ID: <alpine.LSU.2.21.1911121412580.13977@wotan.suse.de> (raw)
In-Reply-To: <8fdf524a-8cdb-8f9e-3b02-104a07f3f072@suse.de>
Hello,
On Tue, 12 Nov 2019, Tom de Vries wrote:
> I reached a feature-complete state for the patch series implementing the
> ODR optimization (PR dwz/24198). [ Feature-complete meaning, AFAICT it
> does what it's supposed to do, though it may be able to do it quicker
> and/or using less memory. ]
That's awecome! I was looking forward to this for some time ;-) Let's
look at the compression impact:
> $ dwz -l50000000 cc1 -o 1
> $ dwz -l50000000 cc1 -o 2 --odr
> $ dwz -l50000000 cc1 -o 3 --odr-unify
> ...
> $ diff.sh cc1 1
> .debug_info red: 44.80% 111527248 61570632
> .debug_abbrev red: 40.16% 1722726 1030935
> $ diff.sh cc1 2
> .debug_info red: 55.16% 111527248 50019425
> .debug_abbrev red: 68.13% 1722726 549035
> $ diff.sh cc1 3
> .debug_info red: 58.18% 111527248 46649959
> .debug_abbrev red: 79.57% 1722726 352080
So, while it is an appreciable reduction I somehow hoped for even more.
Which probably means that type information, at least in the --odr-unify
file, isn't the largest component of .debug_info anymore. I wonder what
the large components are now. (I'm not sure how to measure this, possibly
some size measure per DIE type or a subset of DIE types, or even
attributes (so that one could say that so and so many bytes are associated
with variable location descriptions, and so and so many by subprogram
descriptions, and types, and so on)).
(And I note that --odr-unify is faster than no option, with -DODR, and the
same time as without -DODR ;-) )
Ciao,
Michael.
next prev parent reply other threads:[~2019-11-12 14:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-01 0:00 Tom de Vries
2019-01-01 0:00 ` Michael Matz [this message]
2019-01-01 0:00 ` Tom de Vries
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=alpine.LSU.2.21.1911121412580.13977@wotan.suse.de \
--to=matz@suse.de \
--cc=dwz@sourceware.org \
--cc=jakub@redhat.com \
--cc=mark@klomp.org \
--cc=tdevries@suse.de \
/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).