From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15894 invoked by alias); 24 Oct 2014 16:07:34 -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 15878 invoked by uid 89); 24 Oct 2014 16:07:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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-yh0-f52.google.com Received: from mail-yh0-f52.google.com (HELO mail-yh0-f52.google.com) (209.85.213.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 16:07:32 +0000 Received: by mail-yh0-f52.google.com with SMTP id f10so1169961yha.39 for ; Fri, 24 Oct 2014 09:07:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.130.202 with SMTP id w193mr7789541ykb.22.1414166850891; Fri, 24 Oct 2014 09:07:30 -0700 (PDT) Received: by 10.170.140.214 with HTTP; Fri, 24 Oct 2014 09:07:30 -0700 (PDT) In-Reply-To: <20141024073308.GA20087@host2.jankratochvil.net> References: <20141020214410.GA22011@host2.jankratochvil.net> <20141023182434.GA31412@host2.jankratochvil.net> <20141024073308.GA20087@host2.jankratochvil.net> Date: Fri, 24 Oct 2014 16:07:00 -0000 Message-ID: Subject: Re: [patchv2 2/2] Accelerate lookup_symbol_aux_objfile 14.5x [Re: [patch 0/2] Accelerate symbol lookups 15x] From: Doug Evans To: Jan Kratochvil Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00655.txt.bz2 On Fri, Oct 24, 2014 at 12:33 AM, Jan Kratochvil wrote: > On Fri, 24 Oct 2014 09:16:01 +0200, Doug Evans wrote: >> One thought I have is that significant changes at a higher level will >> minimize the impact of this patch. One change I'm thinking of making >> is replacing iterating over every symbol table and then if that fails >> going to the index with instead just going straight to the index: the >> index knows where the symbols are (you mentioned this as well). > > Yes, I tried that first. > > For the performance testcase I provided the issue is in > lookup_symbol_global_iterator_cb(): > > data->result = lookup_symbol_aux_objfile (objfile, GLOBAL_BLOCK, > data->name, data->domain); > if (data->result == NULL) > data->result = lookup_symbol_aux_quick (objfile, GLOBAL_BLOCK, > data->name, data->domain); > > Changing their order does not fix the performance as lookup_symbol_aux_quick() > (that is quick_symbol_functions::lookup_symbol) can return NULL > * either if the symbol is really not present in the index. > * or if the symbol's symtab is already expanded. > > For the latter case (commonly happening) quick_symbol_functions::lookup_symbol > finds the right symtab but then it drops that information. > > Changing the quick_symbol_functions::lookup_symbol semantics may fix it. Yeah, the experiment I want to try is a bit more invasive such that, for example, we only go to the index (and expand any symtabs found if necessary and only search those ones). E.g., If the index returns NULL there's no point in searching the full set of symtabs. > But then it will get fixed only for .gdb_index files while my two patches also > improve performance of non-.gdb_index files. That's still an open issue, sure. > For each objfile .gdb_index presence is orthogonal to DWZ application. > > Sure a question remains if we should care about performance of non-.gdb_index > files at all. Even for continuous edit-build-debug cycles it is worth to run > gdb-add-index during each build. Or have the compiler/linker build the index.