From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19684 invoked by alias); 12 Jan 2015 17:13:32 -0000 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 Received: (qmail 19669 invoked by uid 89); 12 Jan 2015 17:13:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 12 Jan 2015 17:13:29 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0CHDR4M026368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Jan 2015 12:13:27 -0500 Received: from host2.jankratochvil.net (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0CHDMpb023046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jan 2015 12:13:26 -0500 Date: Mon, 12 Jan 2015 17:13:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: ping^2: [patchv2] Fix 100x slowdown regression on DWZ files Message-ID: <20150112171322.GA14267@host2.jankratochvil.net> References: <21548.37770.274873.760290@ruffy2.mtv.corp.google.com> <20141002155653.GA9001@host2.jankratochvil.net> <20141231192335.GA8188@host2.jankratochvil.net> <21677.57646.178793.836948@ruffy2.mtv.corp.google.com> <21679.8603.893816.420021@ruffy2.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21679.8603.893816.420021@ruffy2.mtv.corp.google.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00303.txt.bz2 On Fri, 09 Jan 2015 01:32:27 +0100, Doug Evans wrote: > Doug Evans writes: > > Do hashtables support calling htab_find_slot with INSERT but then > > not assigning the slot a value if it was empty? > > I could be wrong but I think it does. > > If so, we can remove one call to htab_find_slot here. > > I was wrong. > I thought I was, but I couldn't remember, and couldn't remember where > I had seen this. But htab_find_slot_with_hash does assume > that if you call it with INSERT, and the slot isn't already used, > then you're going to fill in the slot. > No matter, it was just a thought. Maybe one could use HTAB_DELETED_ENTRY in such case? But I find that needless microoptimization. This is solved by compilers this century. And much faster avoiding all the pointer dereferences which is all that matters. But I can use at least htab_find_slot_with_hash instead of htab_find_slot. Jan