From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30910 invoked by alias); 20 Feb 2004 16:52:38 -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 30848 invoked from network); 20 Feb 2004 16:52:36 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 20 Feb 2004 16:52:36 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 8EE4AB660; Fri, 20 Feb 2004 08:52:35 -0800 (PST) To: gdb@sources.redhat.com Subject: Re: Huge slowdown since 6.0 References: <20040218210927.GA16641@nevyn.them.org> <20040220050905.GA15209@nevyn.them.org> From: David Carlton Date: Fri, 20 Feb 2004 16:52:00 -0000 In-Reply-To: <20040220050905.GA15209@nevyn.them.org> (Daniel Jacobowitz's message of "Fri, 20 Feb 2004 00:09:06 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-02/txt/msg00278.txt.bz2 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? David Carlton carlton@kealia.com