From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32170 invoked by alias); 12 Jan 2015 17:26:33 -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 32154 invoked by uid 89); 12 Jan 2015 17:26:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f172.google.com Received: from mail-ob0-f172.google.com (HELO mail-ob0-f172.google.com) (209.85.214.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 12 Jan 2015 17:26:31 +0000 Received: by mail-ob0-f172.google.com with SMTP id va8so23380854obc.3 for ; Mon, 12 Jan 2015 09:26:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RAv66y6v/7wW43ZEf8TmbyqyoN9UFXs0K7ChtUJ9OhA=; b=DN3z6Xeyg/XkLaTjEit4RW7b3i9VoQ5x6mmbSm+nk9sAAqSVqGlW7rWLbI4FvgC2CB Si1mZqiZ/rd6heFhXjfpu42z8P3VpCCxEcnYPR4rZ+3nYRJIvAEc4MKEhhvmGjCnUYuh Ehn2sOJrFTAM/kRcy54N+GKTdm4DvVD+tPzSaPwbSP5lt1FI1GeZ5o+MKwPQ4z9QzhqD zPEaj6znyOVO2pK4HBaye8Eb/zxLt3RMRz6nNAODdo9pMOfanIcWPxk9vtG8CExNEtnK +xv17Gqxe4FA3U2GjCYRe+8/iFutX00LYvNrVsq4nUzHyo/UHJlNMbhKrtMzbjmFJTDb KE1Q== X-Gm-Message-State: ALoCoQlOr5kfCf1toHiV/ABBt0eCblxwZ+YEgb0YvUqWCEP2+9GPi/oRd5waQUho/Zdhh8rWu4ho MIME-Version: 1.0 X-Received: by 10.202.59.136 with SMTP id i130mr16822820oia.114.1421083589623; Mon, 12 Jan 2015 09:26:29 -0800 (PST) Received: by 10.182.222.98 with HTTP; Mon, 12 Jan 2015 09:26:29 -0800 (PST) In-Reply-To: <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> <20150112171322.GA14267@host2.jankratochvil.net> Date: Mon, 12 Jan 2015 17:26:00 -0000 Message-ID: Subject: Re: ping^2: [patchv2] Fix 100x slowdown regression on DWZ files From: Doug Evans To: Jan Kratochvil Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00306.txt.bz2 On Mon, Jan 12, 2015 at 9:13 AM, Jan Kratochvil wrote: > 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. For reference sake, This was never about "microoptimization". It was about code readability.