From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28107 invoked by alias); 20 Feb 2004 17:35:48 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28100 invoked from network); 20 Feb 2004 17:35:47 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 20 Feb 2004 17:35:47 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 724A81A448A; Fri, 20 Feb 2004 12:31:20 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.17512.395259.505177@localhost.redhat.com> Date: Fri, 20 Feb 2004 17:35:00 -0000 To: David Carlton Cc: gdb@sources.redhat.com Subject: Re: Huge slowdown since 6.0 In-Reply-To: References: <20040218210927.GA16641@nevyn.them.org> <20040220050905.GA15209@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00285.txt.bz2 David Carlton writes: > On Fri, 20 Feb 2004 00:09:06 -0500, Daniel Jacobowitz said: > > My testcase is in C. > > > These are all conditionalized on language_cplus. > > > How can they possibly be to blame? Well, they are. And reverting the > > change for enumerators definitely won't do any harm. Take a look at > > this, read it two or three times if necessary - it took me about a > > dozen: > > >> > - &objfile->static_psymbols, > >> > + cu_language == language_cplus > >> > + ? &objfile->static_psymbols > >> > + : &objfile->global_psymbols, > > > If I swap "static" and "global", it reduces GDB startup time by roughly > > 40% for glibc with debug information, which contains a lot of C > > enumerators. I assume that is what you meant to do in the first > > place? > > Um, yeah. Oops. That would qualify as an obvious fix. > > There's one other interesting point here - where exactly is the > slowdown coming from? After all, we generate the same number of > searches, and lookup_symbol can potentially look at all the static > psymbols just like it could look at all the global psymbols. Not only > that, but looking at the static psymbols is vastly slower than looking > at the global psymbols (for no good reason, as far as I know, but > that's a separate issue; lookup_partial_symbol has issues). > > But I suppose the point is that looking at all the static psymbols is > only a very last resort in lookup_symbol, so (as long as the symbol > you're looking for actually exists) it wouldn't get called very often. > > Or is there something else that I'm missing? No lookup yet. Only reading the debuginfo and sorting *only the globals*. Daniel profiled only the reading of the psymbols part. It threw off me for a while, before I remembered that we only sort the globals psymbols.