From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22716 invoked by alias); 2 Dec 2014 03:07:25 -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 22702 invoked by uid 89); 2 Dec 2014 03:07:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f176.google.com Received: from mail-pd0-f176.google.com (HELO mail-pd0-f176.google.com) (209.85.192.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 02 Dec 2014 03:07:22 +0000 Received: by mail-pd0-f176.google.com with SMTP id y10so12176994pdj.35 for ; Mon, 01 Dec 2014 19:07:21 -0800 (PST) X-Received: by 10.68.57.225 with SMTP id l1mr1518660pbq.87.1417489640886; Mon, 01 Dec 2014 19:07:20 -0800 (PST) Received: from seba.sebabeach.org.gmail.com (173-13-178-50-sfba.hfc.comcastbusiness.net. [173.13.178.50]) by mx.google.com with ESMTPSA id ap5sm18871541pad.22.2014.12.01.19.07.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 19:07:19 -0800 (PST) From: Doug Evans To: Jan Kratochvil Cc: "gdb-patches\@sourceware.org" Subject: Re: [patchv3 2/2] Accelerate lookup_symbol_aux_objfile 85x References: <20141020214410.GA22011@host2.jankratochvil.net> <20141023182434.GA31412@host2.jankratochvil.net> <20141129121124.GA21606@host2.jankratochvil.net> Date: Tue, 02 Dec 2014 03:07:00 -0000 In-Reply-To: <20141129121124.GA21606@host2.jankratochvil.net> (Jan Kratochvil's message of "Sat, 29 Nov 2014 13:11:24 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00029.txt.bz2 Jan Kratochvil writes: > On Fri, 24 Oct 2014 09:16:01 +0200, Doug Evans wrote: >> This breaks an abstraction boundary, IWBN to preserve it. >> [IOW, I look at dict_* as being an implementation detail of blocks.] >> >> If we were to go this route (and apologies for the delay), can you >> write a routine like lookup_block_symbol which does the above and call >> that here instead? >> >> lookup_block_symbol should live in block.c, not symtab.c. >> That's where this new routine should go too. > > Done. > > For the 'slow.C' test the performance gain is even higher; but I have not > re-benchmarked the 'non-trivial app': > Command execution time: 26.540344 (cpu), 26.575254 (wall) > -> > Command execution time: 0.310607 (cpu), 0.311062 (wall) > = 85x > > OK for check-in? > > No regressions on {x86_64,x86_64-m32,i686}-fedora21-linux-gnu native and in > DWZ and in -fdebug-types-section modes. > > > Thanks, > Jan > gdb/ > 2014-11-28 Jan Kratochvil > > * block.c (block_lookup_symbol_primary): New function. > * block.h (block_lookup_symbol_primary): New declaration. > * symtab.c (lookup_symbol_in_objfile_symtabs): Assert BLOCK_INDEX. > Call block_lookup_symbol_primary. Hi. I was reviewing all the callers of lookup_symbol_in_objfile_symtabs. This patch assumes we're looping over all objfiles, but some callers aren't. e.g., lookup_symbol_in_objfile_from_linkage_name. It seems like we'll need to make a copy of lookup_symbol_in_objfile_symtabs and call that in lookup_symbol_in_objfile (plus I'd add some comments to lookup_symbol_in_objfile warning the reader that included symtabs are not searched). I could be missing something though.