From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24855 invoked by alias); 16 Aug 2003 15:11:25 -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 24848 invoked from network); 16 Aug 2003 15:11:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Aug 2003 15:11:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19o2iC-0000kE-UA for ; Sat, 16 Aug 2003 11:11:24 -0400 Date: Sat, 16 Aug 2003 15:11:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: Terminally slow (75 seconds) on some steps Message-ID: <20030816151124.GA2746@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <3F186D0B.5020902@redhat.com> <3F1BF6D4.6090801@redhat.com> <3F2F3E9A.6050403@redhat.com> <3F2FF8F5.6070007@redhat.com> <3F3D65C5.2070005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F3D65C5.2070005@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00169.txt.bz2 On Fri, Aug 15, 2003 at 06:59:17PM -0400, Andrew Cagney wrote: > That's striking. GDB spent 4s/30s avoiding the creation of duplicate > strings and other symbols. The lack of call graph is a shame, useful to > know from where this was called. Hmm, assuming no macro debug info > there are only three calls, all in symtab.c: > > - recording the symbol name (linkage name?) > - recording the demangled name > - recording a partial symbol > > This is to save a significant amount of memory. Often two files will > contain the same partial symbol information (due to headers et.al.). > > It's interesting how linkage and demangled names (strings) share the > same bcache as partial symbol (a struct). Wonder if separate caches > would lead to a better hit rate? > > I also wonder if the full symbols are making use of the partial symbol > name bcache. See SYMBOL_SET_NAMES - I fixed that fairly recently. Also, add_psymbol_to_list is how most partial symbols are added; that uses the same name cache. If you're talking about the call to bcache in add_psymbol_with_dem_name_to_list, it's only used by hpread.c. Fixing this did in fact improve the hit rate. > >c011f6b8 663 2.3393 vmlinux do_anonymous_page > >00000000 622 2.1946 XFree86 (no symbols) > >08134b74 574 2.0253 gdb read_partial_die > > Ok, so its spending a lot of time reading partial symbols. I've got some plans in this direction... just haven't had time to do anything about it yet :( -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer