From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22103 invoked by alias); 19 Feb 2004 03:35:05 -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 22094 invoked from network); 19 Feb 2004 03:35:04 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 19 Feb 2004 03:35:04 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Atexb-0003ow-RF; Wed, 18 Feb 2004 22:34:47 -0500 Date: Thu, 19 Feb 2004 03:35:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: carlton@kealia.com, gdb@sources.redhat.com Subject: Re: Huge slowdown since 6.0 Message-ID: <20040219033447.GA14471@nevyn.them.org> Mail-Followup-To: Elena Zannoni , carlton@kealia.com, gdb@sources.redhat.com References: <20040218210927.GA16641@nevyn.them.org> <16436.5998.22504.266273@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16436.5998.22504.266273@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00236.txt.bz2 On Wed, Feb 18, 2004 at 08:54:54PM -0500, Elena Zannoni wrote: > Daniel Jacobowitz writes: > > I finished prototyping my partial-symbol-sorting changes, as discussed on > > gdb-patches, and went to measure their impact. The results were a little > > confusing, but I've tracked them down. At the bottom of my message are > > profiling numbers if you want to see them. The summary is that I hope they > > won't be needed. > > > > Basically, the bottleneck in strcmp_iw_ordered that I am attacking was not > > there in 6.0. This baffled me. There were just as many psymbols and there > > should have been just as many calls; the change to use strcmp_iw_ordered > > predates 6.0. > > > How many psymbols do you have in the pst list of globals before and > after David's change? All you did was to time the times it took to > insert symbols and sort them, no lookups, right? That's right - just insertion and sorting. Lookups are fast; the binary search isn't quite as nice as a hash table would be but it's still pretty quick. It's just insertion that hurts us. Perhaps a more efficient representation is on order. GDB 6.0: (gdb) p object_files.global_psymbols.size $4 = 3264 (gdb) p object_files.static_psymbols.size $5 = 835584 (gdb) p object_files.stats.n_psyms $3 = 829406 GDB HEAD: (gdb) p object_files.global_psymbols.size $1 = 835584 (gdb) p object_files.static_psymbols.size $2 = 417792 (gdb) p object_files.stats.n_psyms $3 = 829406 Um... I'm not precisely sure why these numbers don't add up. I notice they didn't before either. By the way, do we even need the address field from general_symbol_info in psymbols? I haven't checked thoroughly but I suspect that most of the places we currently use it, the symtab will usually be read in shortly afterwards anyway. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer