very slow gdb stepping.

very slow gdb stepping.

[Paweł Sikora]

Hi all,

during debugging a large c++ application an each gdb step (next or step-in)
takes from ~2 to ~30 seconds which is horribly slow and uncomfortable :(
the callgrind shows some hot places in gdb: http://carme.pld-linux.org/~pluto/gdb-cpuhog/callgraph.png

callgrind results from ~30min session and .rpms are stored here:
http://carme.pld-linux.org/~pluto/gdb-cpuhog/

is it a known issue?

Re: very slow gdb stepping.

[Jan Kratochvil]

On Sat, 31 Mar 2012 15:05:09 +0200, Paweł Sikora wrote:
> during debugging a large c++ application an each gdb step (next or step-in)
> takes from ~2 to ~30 seconds which is horribly slow and uncomfortable :(
[...]
> http://carme.pld-linux.org/~pluto/gdb-cpuhog/

The name gdb-7.4.50-0.20120120 it suggests a snapshot with performance
regression later already fixed on trunk by Tom Tromey.  This performance
regression was not present in 7.4 and it will not be present in 7.5.

I have fixed this regression by a backport in 7.4.50.20120120-35.fc17,
the 20120120 snapshot date may suggest your GDB is somehow Fedora derived.
	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=commitdiff;h=ea0fcb4584cb04c938e32e44ad21a04c6225c5a1
->
	FYI: remove extraneous block from dw2_map_symtabs_matching_filename
	http://sourceware.org/ml/gdb-patches/2012-02/msg00409.html
	FYI: fix some performance bugs with .gdb_index
	http://sourceware.org/ml/gdb-patches/2012-02/msg00413.html


Regards,
Jan

Re: very slow gdb stepping.

[Jan Kratochvil]

On Sat, 31 Mar 2012 23:57:18 +0200, Jan Kratochvil wrote:
> This performance regression was not present in 7.4

In fact it probably is present in 7.4, I did not check it more.


Sorry,
Jan

Re: very slow gdb stepping.

[Paweł Sikora]

On Saturday 31 of March 2012 23:57:18 Jan Kratochvil wrote:
> On Sat, 31 Mar 2012 15:05:09 +0200, Paweł Sikora wrote:
> > during debugging a large c++ application an each gdb step (next or step-in)
> > takes from ~2 to ~30 seconds which is horribly slow and uncomfortable :(
> [...]
> > http://carme.pld-linux.org/~pluto/gdb-cpuhog/
> 
> The name gdb-7.4.50-0.20120120 it suggests a snapshot with performance
> regression later already fixed on trunk by Tom Tromey.  This performance
> regression was not present in 7.4 and it will not be present in 7.5.
> 
> I have fixed this regression by a backport in 7.4.50.20120120-35.fc17,
> the 20120120 snapshot date may suggest your GDB is somehow Fedora derived.
> 	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=commitdiff;h=ea0fcb4584cb04c938e32e44ad21a04c6225c5a1
> ->
> 	FYI: remove extraneous block from dw2_map_symtabs_matching_filename
> 	http://sourceware.org/ml/gdb-patches/2012-02/msg00409.html
> 	FYI: fix some performance bugs with .gdb_index
> 	http://sourceware.org/ml/gdb-patches/2012-02/msg00413.html
> 

didn't help too much. callgrind still shows zilion calls to glibc's strcmp
from filename_cmp and start_subfile. our c++ project contains lot of files:

$ find sources -type f -name '*.?pp' |wc -l
6947
$ find buildenv -type f -name '*.?pp' |wc -l
8906

on each step in 95% of cases gdb deduces language for the same files 
(e.g. libstdc++, boost and common application headers). moreover the gdb
performs deduce_language_from_filename for each file *twice* (buildsym.c:585 and :607).

finally 'set language c++' doesn't disable auto deducing :(

Re: very slow gdb stepping.

[Paweł Sikora]

On Saturday 31 of March 2012 23:57:18 Jan Kratochvil wrote:
> On Sat, 31 Mar 2012 15:05:09 +0200, Paweł Sikora wrote:
> > during debugging a large c++ application an each gdb step (next or step-in)
> > takes from ~2 to ~30 seconds which is horribly slow and uncomfortable :(
> [...]
> > http://carme.pld-linux.org/~pluto/gdb-cpuhog/
> 
> The name gdb-7.4.50-0.20120120 it suggests a snapshot with performance
> regression later already fixed on trunk by Tom Tromey.  This performance
> regression was not present in 7.4 and it will not be present in 7.5.
> 
> I have fixed this regression by a backport in 7.4.50.20120120-35.fc17,
> the 20120120 snapshot date may suggest your GDB is somehow Fedora derived.
> 	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=commitdiff;h=ea0fcb4584cb04c938e32e44ad21a04c6225c5a1
> ->
> 	FYI: remove extraneous block from dw2_map_symtabs_matching_filename
> 	http://sourceware.org/ml/gdb-patches/2012-02/msg00409.html
> 	FYI: fix some performance bugs with .gdb_index
> 	http://sourceware.org/ml/gdb-patches/2012-02/msg00413.html

one more observation: during stepping the collect_symtabs_from_filename
is called many [*] times for the same file which looks suboptimal for large
binaries and linear list scanning in start_subfile.

[*]

#0  collect_symtabs_from_filename (file=0x505b4f0 "ProjectManager.cpp") at linespec.c:2123
#1  0x000000000054c924 in symtabs_from_filename (user_filename=0x7fff5fc4f2d0, is_quote_enclosed=<optimized out>, p=<optimized out>, argptr=0x7fff5fc4f5a0) at
 linespec.c:2175
#2  decode_line_internal (self=0x7fff5fc4f2b0, argptr=0x7fff5fc4f5a0) at linespec.c:912
#3  0x000000000054e1eb in decode_line_full (argptr=0x7fff5fc4f5a0, flags=<optimized out>, default_symtab=<optimized out>, default_line=<optimized out>, canoni
cal=0x7fff5fc4f3b0, select_mode=0x739a37 "all", filter=0x0) at linespec.c:1223
#4  0x000000000050244a in decode_linespec_default (s=0x7fff5fc4f5a0, sals=0x7fff5fc4f570, b=<optimized out>) at breakpoint.c:12300
#5  0x0000000000508fce in addr_string_to_sals (b=0x1dc7af0, addr_string=<optimized out>, found=0x7fff5fc4f65c) at breakpoint.c:12159
#6  0x000000000050d44b in breakpoint_re_set_default (b=0x1dc7af0) at breakpoint.c:12235
#7  0x00000000004feff7 in breakpoint_re_set_one (bint=0x1dc7af0) at breakpoint.c:12350
#8  0x000000000056b1db in catch_errors (func=0x4fefb0 <breakpoint_re_set_one>, func_args=0x1dc7af0, errstring=0x3e3a5b0 "Error in re-setting breakpoint 1: ",
mask=6) at exceptions.c:546
#9  0x000000000050d5d2 in breakpoint_re_set () at breakpoint.c:12374
(...)