From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7855 invoked by alias); 4 Jul 2006 01:06:43 -0000 Received: (qmail 7843 invoked by uid 22791); 4 Jul 2006 01:06:42 -0000 X-Spam-Check-By: sourceware.org Received: from omta01sl.mx.bigpond.com (HELO omta01sl.mx.bigpond.com) (144.140.92.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Jul 2006 01:06:39 +0000 Received: from grove.modra.org ([60.226.255.233]) by omta01sl.mx.bigpond.com with ESMTP id <20060704010636.QFZJ3114.omta01sl.mx.bigpond.com@grove.modra.org>; Tue, 4 Jul 2006 01:06:36 +0000 Received: by bubble.grove.modra.org (Postfix, from userid 500) id 96C8554DD9; Tue, 4 Jul 2006 10:36:35 +0930 (CST) Date: Tue, 04 Jul 2006 01:06:00 -0000 From: Alan Modra To: Jakub Jelinek Cc: binutils@sources.redhat.com Subject: Re: [PATCH] Fix compute_bucket_count Message-ID: <20060704010635.GQ4388@bubble.grove.modra.org> Mail-Followup-To: Jakub Jelinek , binutils@sources.redhat.com References: <20060623155502.GT3823@sunsite.mff.cuni.cz> <20060703061352.GP4388@bubble.grove.modra.org> <20060703084231.GB3823@sunsite.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060703084231.GB3823@sunsite.mff.cuni.cz> User-Agent: Mutt/1.4i X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00025.txt.bz2 On Mon, Jul 03, 2006 at 10:42:31AM +0200, Jakub Jelinek wrote: > On Mon, Jul 03, 2006 at 03:43:52PM +0930, Alan Modra wrote: > > I'm not so sure about this change, which affects both 32-bit and > > 64-bit. If I've analysed the change correctly, it will tend to result > > in smaller hash tables at the expense of possibly longer chains, in both > > the optimising and non-optimising cases. Do we really want that? > > Well, if we want to use a bigger number, we certainly can, not sure if > we want some multiply of (hashcodesp - hashcodes) or just add some constant > (i.e. say (hashcodesp - hashcodes) * 1.1 < elf_buckets[i + 1] or > (hashcodesp - hashcodes) + 20 < elf_buckets[i + 1]). No, I don't want to see fudge factors like this! > What I'm just trying > to say that the heuristics should have nothing to do with dynsymcount, > it really shouldn't care how many special symbols you have in .dynsym that > are not added to the hash table. Yes, I agree with your change from a logical perspective. I wasn't saying that I disliked the new heuristic, just noting that your change potentially causes longer chains. Have you done any tests to see whether there is in fact any real world effect? -- Alan Modra IBM OzLabs - Linux Technology Centre