From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1228 invoked by alias); 20 Feb 2004 17:45:33 -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 1202 invoked from network); 20 Feb 2004 17:45:31 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 20 Feb 2004 17:45:31 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 45A461A448A; Fri, 20 Feb 2004 12:41:04 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.18096.205403.553354@localhost.redhat.com> Date: Fri, 20 Feb 2004 17:45:00 -0000 To: Andrew Cagney Cc: Elena Zannoni , Daniel Jacobowitz , David Carlton , gdb@sources.redhat.com Subject: Re: Huge slowdown since 6.0 In-Reply-To: <40363D78.9080708@gnu.org> References: <20040218210927.GA16641@nevyn.them.org> <20040220050905.GA15209@nevyn.them.org> <16438.14300.323849.306261@localhost.redhat.com> <40363D78.9080708@gnu.org> X-SW-Source: 2004-02/txt/msg00286.txt.bz2 Andrew Cagney writes: > > Daniel Jacobowitz writes: > > > 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? > > > If so I can recover the speed hit for C for GDB 6.1, and then address > > > the larger issues with large numbers of global psymbols in HEAD after > > > we branch. > > > > Another point in favor of the theory that conditional expressions are > > bad. > > > > This should be fine, consider it preapproved. However, what you are > > really saying is that qsort performance is really bad in case we have > > lots of symbols to sort. But how many symbols? You didn't post the > > numbers. > > Hmm, begs a few questions: sorry, I am talking about partial symbols. It's not clear from the above. > > - why do we load the symbols during startup? > Load globals on demand? > - why do we sort the symbols during startup? > Use a hash (so that break main is fast) and sort when (break main > is entered?) > - why don't we do more while GDB is twiddling its thumbs in the event > loop event loop? The thing that I am curious about is to see how early into a regular debug session we build the symtabs. I.e. I am afraid that any reference to any symbol from the command line makes the whole lot expand anyway. The answer to this may help answer the question whether we really need a two tier symbol table system, or if there is another way of solving the same problem. While cleaning up the obstack stuff, it became obvious that the intent was for the psymtabs to go away once expanded into full symtabs, but this was never implemented.