From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28528 invoked by alias); 18 Oct 2011 09:49:43 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 28518 invoked by uid 22791); 18 Oct 2011 09:49:43 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Date: Tue, 18 Oct 2011 09:49:00 -0000 From: Jan Kratochvil To: Mark Wielaard Cc: Project Archer Subject: Re: gcc dwarf2out: Drop the size + performance overhead of DW_AT_sibling Message-ID: <20111018094924.GA3571@host1.jankratochvil.net> References: <201110170508.p9H581vh028090@shell.devel.redhat.com> <20111017133634.GA5677@host1.jankratochvil.net> <1318929963.8669.2.camel@springer.wildebeest.org> <20111018094457.GB2412@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111018094457.GB2412@host1.jankratochvil.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2011-q4/txt/msg00001.txt.bz2 On Tue, 18 Oct 2011 11:44:57 +0200, Jan Kratochvil wrote: > 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. maybe it could be worth tune out specific special cases where DW_AT_sibling skips larger set of DIEs and any of the consumers benefits from that case. Just at least in the case of GDB there are so many several orders of magnitude worse performance issues than reading out the CU data that I do not think it matters much and the on-disk size should be the primary concern even even if would mean some performance degradation, which will not be much measurable. It is true systemtap is a different kind of consumer, thanks for pointing it out. Thanks, Jan