Bug 9359 - Symbol loading in GDB too slow
Summary: Symbol loading in GDB too slow
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: 6.6
: P3 enhancement
Target Milestone: 7.3
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-15 20:48 UTC by thomas.mcguire
Modified: 2010-07-13 21:17 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description drow@false.org 2007-04-15 22:15:09 UTC
From: Daniel Jacobowitz <drow@false.org>
To: Thomas.McGuire@gmx.net
Cc: gdb-gnats@sources.redhat.com
Subject: Re: symtab/2254: Symbol loading in GDB too slow
Date: Sun, 15 Apr 2007 18:15:09 -0400

 On Sun, Apr 15, 2007 at 07:41:57PM -0000, Thomas.McGuire@gmx.net wrote:
 > Attaching GDB to such a process takes about 5 minutes on my PC, mainly due to symbol loading. 
 > Although I only have a 1.8GHZ CPU with 384MB RAM, this should be faster.
 > 
 > Partly, the slowness is caused by a lot of swapping due to my low memory. I think GDB should use much less memory for the symbol tables if that is possible.
 > 
 > Additionally, the symbol loading is too slow. Either it could be fixed by optimizing the code or by introducing a on-disk symbol cache.
 
 Symbol table loading is already heavily optimized.  GDB can't give you
 miracles; how big are the libraries that you're trying to debug, and
 how big are their debugging symbols?
 
 We're always interested in clever ways to make it go faster.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 1 thomas.mcguire 2007-04-16 02:48:01 UTC
[Converted from Gnats 2254]

Symbol loading in GDB seems to very inefficient. This is very noticeable in large C++ applications with many libraries, like some KDE apps.

Attaching GDB to such a process takes about 5 minutes on my PC, mainly due to symbol loading. 
Although I only have a 1.8GHZ CPU with 384MB RAM, this should be faster.

Partly, the slowness is caused by a lot of swapping due to my low memory. I think GDB should use much less memory for the symbol tables if that is possible.

Additionally, the symbol loading is too slow. Either it could be fixed by optimizing the code or by introducing a on-disk symbol cache.

Release:
6.6

Environment:
Linux 2.6.17-11-generic #2 SMP Tue Mar 13 23:32:38 UTC 2007 i686 GNU/Linux
Ubuntu 6.10
Comment 2 thomas.mcguire 2007-04-16 14:35:06 UTC
From: Thomas McGuire <Thomas.McGuire@gmx.net>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: symtab/2254: Symbol loading in GDB too slow
Date: Mon, 16 Apr 2007 16:35:06 +0200

 > Symbol table loading is already heavily optimized.  GDB can't give you
 > miracles; how big are the libraries that you're trying to debug, 
 Seems like the libraries are indeed quite big. After issuing ldd kmail (which gave me 100 different libraries), I used ls -l -h on some of them which I suspected to be the bigest:
 
 62M 2007-04-15 13:08 /media/kdedev/home/build/KDE/kdepim/lib/libkmailprivate.so.1.0.0
 7.6M 2007-04-10 22:36 /media/kdedev/home/kde/lib/libkde3support.so.5.0.0
 21M 2007-04-10 22:35 /media/kdedev/home/kde/lib/libkdecore.so.5.0.0
 15M 2007-04-15 13:16 /media/kdedev/home/kde/lib/libkdepim.so.5.0.0
 42M 2007-04-10 22:36 /media/kdedev/home/kde/lib/libkdeui.so.5.0.0
 54M 2007-04-10 22:37 /media/kdedev/home/kde/lib/libkhtml.so.5.0.0
 37M 2007-04-10 22:36 /media/kdedev/home/kde/lib/libkio.so.5.0.0
 3.3M 2007-03-28 00:08 /media/kdedev/home/qt-copy/lib/libQt3Support.so.4.3.0
 1.9M 2007-03-27 23:46 /media/kdedev/home/qt-copy/lib/libQtCore.so.4.3.0
 9.1M 2007-03-27 23:59 /media/kdedev/home/qt-copy/lib/libQtGui.so.4.3.0
 
 >and how big are their debugging symbols?
 What command can I use to find out?
 
 At least this seems to explain why GDB uses that much memory.
 
 If it is already heavily optimized, do you think caching on disk would gain anything at all?
 
 

Comment 3 drow@false.org 2007-04-16 15:02:05 UTC
From: Daniel Jacobowitz <drow@false.org>
To: Thomas McGuire <Thomas.McGuire@gmx.net>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: symtab/2254: Symbol loading in GDB too slow
Date: Mon, 16 Apr 2007 11:02:05 -0400

 On Mon, Apr 16, 2007 at 04:35:06PM +0200, Thomas McGuire wrote:
 > > Symbol table loading is already heavily optimized.  GDB can't give you
 > > miracles; how big are the libraries that you're trying to debug, 
 > Seems like the libraries are indeed quite big. After issuing ldd kmail (which gave me 100 different libraries), I used ls -l -h on some of them which I suspected to be the bigest:
 > 
 > 62M 2007-04-15 13:08 /media/kdedev/home/build/KDE/kdepim/lib/libkmailprivate.so.1.0.0
 > 7.6M 2007-04-10 22:36 /media/kdedev/home/kde/lib/libkde3support.so.5.0.0
 > 21M 2007-04-10 22:35 /media/kdedev/home/kde/lib/libkdecore.so.5.0.0
 > 15M 2007-04-15 13:16 /media/kdedev/home/kde/lib/libkdepim.so.5.0.0
 > 42M 2007-04-10 22:36 /media/kdedev/home/kde/lib/libkdeui.so.5.0.0
 > 54M 2007-04-10 22:37 /media/kdedev/home/kde/lib/libkhtml.so.5.0.0
 > 37M 2007-04-10 22:36 /media/kdedev/home/kde/lib/libkio.so.5.0.0
 > 3.3M 2007-03-28 00:08 /media/kdedev/home/qt-copy/lib/libQt3Support.so.4.3.0
 > 1.9M 2007-03-27 23:46 /media/kdedev/home/qt-copy/lib/libQtCore.so.4.3.0
 > 9.1M 2007-03-27 23:59 /media/kdedev/home/qt-copy/lib/libQtGui.so.4.3.0
 > 
 > >and how big are their debugging symbols?
 > What command can I use to find out?
 
 You can look at the size of .debug_info with readelf -S, but it won't
 tell us much; it's always roughly the same proportion of file size for
 C++.  I estimate you have about 150MB of DWARF-2 information (plus or
 minus a hundred percent :-).  DWARF-2 is designed to be compact on
 disk; useful memory representations tend to be bigger.
 
 I would be reluctant to debug KDE on something with <1GB RAM.
 
 > If it is already heavily optimized, do you think caching on disk would gain anything at all?
 
 Possibly, since it could be more easily paged out by the OS if we
 could use it unmodified.  But it would be a fair amount of work to
 design a useful cache.
 
 I think there are also some C++-specific optimizations possible.  For
 instance we waste some memory by our representation of demangled
 names, especially for templates.  I had a discussion the Michael Matz
 on the GCC list some months ago about this; it requires compiler
 assistance to get it right.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 4 thomas.mcguire 2007-05-13 21:15:00 UTC
From: Thomas McGuire <thomas.mcguire@gmx.net>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: symtab/2254: Symbol loading in GDB too slow
Date: Sun, 13 May 2007 23:15:00 +0200

 > I would be reluctant to debug KDE on something with <1GB RAM.
 I today upgraded from 384 MB RAM to 2GB RAM and from 1.8GHz to 2x3.4GHz and 
 the difference is like night and day. Previously, starting KMail in GDB took 
 maybe 5 minutes, now it is down to a ~15 seconds. really incredible.
 Still, symbol loading takes the most (allmost all) time of starting.
 
 But anyway, this problem here now does not affect me anymore :)
Comment 5 Tom Tromey 2010-07-13 21:17:34 UTC
I think the just-committed DWARF index work addresses this bug.
So, I am closing it.