From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11438 invoked by alias); 4 Oct 2004 21:17:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11431 invoked from network); 4 Oct 2004 21:17:48 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Oct 2004 21:17:48 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i94LHhKM009352 for ; Mon, 4 Oct 2004 17:17:43 -0400 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i94LHgr25780; Mon, 4 Oct 2004 17:17:42 -0400 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/dwarf] Support for attributes pointing to a different CU References: <20040923045723.GA11871@nevyn.them.org> <20040924003412.GB10500@nevyn.them.org> <20041003161221.GA3234@nevyn.them.org> From: Jim Blandy Date: Mon, 04 Oct 2004 21:17:00 -0000 In-Reply-To: <20041003161221.GA3234@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-10/txt/msg00066.txt.bz2 Daniel Jacobowitz writes: > On Wed, Sep 29, 2004 at 12:49:35PM -0500, Jim Blandy wrote: > > Since we never toss types anyway, would it make sense to move > > type_hash to dwarf2_per_objfile? > > I don't think so. type_hash is used in two ways: individual items are > set, when we know which CU we ought to have, and a whole CU is > restored, when we know which CU we're restoring. It's always more > efficient to have a lot of small hash tables if you know precisely > which one you'll need; fewer collisions. Really? libiberty/hashtab.c is a resizing hash table; I thought hash table resizing was supposed to keep the collision rate roughly constant (modulo hysteresis) regardless of the number of elements. If that's not so, doesn't that mean your hash function isn't doing its job spreading the elements across the (adequately sized) table?