From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65564 invoked by alias); 12 Nov 2019 14:20:40 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 65553 invoked by uid 89); 12 Nov 2019 14:20:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*Ad:U*mark X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: mx1.suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Date: Tue, 01 Jan 2019 00:00:00 -0000 From: Michael Matz To: Tom de Vries cc: dwz@sourceware.org, Jakub Jelinek , Mark Wielaard Subject: Re: [RFC] Implement C++ One Definition Rule for struct, class and union In-Reply-To: <8fdf524a-8cdb-8f9e-3b02-104a07f3f072@suse.de> Message-ID: References: <8fdf524a-8cdb-8f9e-3b02-104a07f3f072@suse.de> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019-q4/txt/msg00047.txt.bz2 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.