Sources Bugzilla – Bug 9359
Symbol loading in GDB too slow
Last modified: 2010-07-13 21:17:34 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
[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
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?
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
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 :)
I think the just-committed DWARF index work addresses this bug. So, I am closing it.