From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7230 invoked by alias); 19 Nov 2003 21:13:58 -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 7222 invoked from network); 19 Nov 2003 21:13:56 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 19 Nov 2003 21:13:56 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AMZe7-00086D-Ug; Wed, 19 Nov 2003 16:13:55 -0500 Date: Wed, 19 Nov 2003 21:13:00 -0000 From: Daniel Jacobowitz To: Will Cohen Cc: gdb@sources.redhat.com Subject: Re: Slow handling of C++ symbol names Message-ID: <20031119211355.GA31069@nevyn.them.org> Mail-Followup-To: Will Cohen , gdb@sources.redhat.com References: <3FBBDC27.50204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBBDC27.50204@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00159.txt.bz2 First of all, please use gdb@, not gdb-patches@. On Wed, Nov 19, 2003 at 04:09:59PM -0500, Will Cohen wrote: > When debugging some C++ program with gdb (both versions 5.3 and 6.0) it > takes a long time to load the debugging information and get a > command-line prompt. The particular example that demonstrates this > problem is monotone (http://www.venge.net/monotone/) which makes use of > the boost libraries (http://www.boost.org/). gdb loading monotone with > the associated debugging information takes over 30 seconds to get the > initial command-line prompt on a 1.7GHz Athlon with 512MB or DRAM. > monotone is not a small program, over 3MB of debugging information. I > tooks some measurements with OProfile to find out where gdb 5.3 was > spending its time. 3/4 of the time is spent in dyn_string_substring and > __GI_strncpy, the column below the '%'. I recompiled gdb with '-pg' to > find that this is due to the C++ name demangling. The highlights of > gprof output are shown below. I looked at the symbols for monotone/boost > in the executable, some of them are VERY long and for monotone/boost > they average 147 characters in length. An example of ONE symbol over 2KB > is at the end of this mail (there are others like that). I suspect that > some of the algorithms used in gdb may not expect such long symbol names > and be part of the reason for the slow startup, e.g. work > O(length_of_string ^2). Has anyone else noticed this type of problem before? Have you tried a more recent version of GDB? This may have been improved. Definitely some startup time issues were fixed. Also, the demangler actually comes from GCC, not GDB. All we can do is try to call it less often. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer