From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31090 invoked by alias); 9 Sep 2010 16:16:02 -0000 Received: (qmail 31080 invoked by uid 22791); 9 Sep 2010 16:16:01 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Sep 2010 16:15:54 +0000 Received: (qmail 21401 invoked from network); 9 Sep 2010 16:15:52 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Sep 2010 16:15:52 -0000 Date: Thu, 09 Sep 2010 19:55:00 -0000 From: Daniel Jacobowitz To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [RFA] symtab/11942: rewrite dwarf2read.c type_hash usage Message-ID: <20100909161546.GB19645@caradoc.them.org> Mail-Followup-To: Doug Evans , gdb-patches@sourceware.org References: <20100824000327.7787684B8E@ruffy.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100824000327.7787684B8E@ruffy.mtv.corp.google.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00204.txt.bz2 On Mon, Aug 23, 2010 at 05:03:27PM -0700, Doug Evans wrote: > The basic idea here is that instead of having one type_hash per CU, > we have one type_hash for dies from .debug_info and have another type_hash > for dies from .debug_types. Types are hashed based on the associated > die's offset and are not freed when a CUs dwarf2_cu structure is freed, > thus I can't see a need for one type_hash per CU. FWIW, I believe I chose this way for performance. If we have the DIE, we have the CU, and this keeps the hash tables smaller and makes it easier to estimate their size. Sure, lookups are O(1), but there's also both cache behavior and the cost of resizing during read-in to consider. I did a whole lot of benchmarking, and the "cu->header.length / 24" worked out well. Things have changed since then, though, not least Tom's index support. > Plus, when looking up a type for a given die, gdb first reads in the > die at the given offset and then looks up the type for the die at that > offset. Since we hash types based on die offsets, I can't see a reason > why we don't just lookup the type for the die at the given offset first, > and only if that fails read in the die (this is useful, e.g., when > dies have been flushed because the CU has reached max-cache-age). This part makes total sense. Duh! -- Daniel Jacobowitz CodeSourcery