* very slow gdb stepping. @ 2012-03-31 13:05 Paweł Sikora 2012-03-31 21:57 ` Jan Kratochvil 0 siblings, 1 reply; 5+ messages in thread From: Paweł Sikora @ 2012-03-31 13:05 UTC (permalink / raw) To: gdb 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: very slow gdb stepping. 2012-03-31 13:05 very slow gdb stepping Paweł Sikora @ 2012-03-31 21:57 ` Jan Kratochvil 2012-03-31 22:01 ` Jan Kratochvil ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Jan Kratochvil @ 2012-03-31 21:57 UTC (permalink / raw) To: Paweł Sikora; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: very slow gdb stepping. 2012-03-31 21:57 ` Jan Kratochvil @ 2012-03-31 22:01 ` Jan Kratochvil 2012-04-01 9:19 ` Paweł Sikora 2012-04-01 10:44 ` Paweł Sikora 2 siblings, 0 replies; 5+ messages in thread From: Jan Kratochvil @ 2012-03-31 22:01 UTC (permalink / raw) To: Paweł Sikora; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: very slow gdb stepping. 2012-03-31 21:57 ` Jan Kratochvil 2012-03-31 22:01 ` Jan Kratochvil @ 2012-04-01 9:19 ` Paweł Sikora 2012-04-01 10:44 ` Paweł Sikora 2 siblings, 0 replies; 5+ messages in thread From: Paweł Sikora @ 2012-04-01 9:19 UTC (permalink / raw) To: Jan Kratochvil; +Cc: gdb 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 :( ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: very slow gdb stepping. 2012-03-31 21:57 ` Jan Kratochvil 2012-03-31 22:01 ` Jan Kratochvil 2012-04-01 9:19 ` Paweł Sikora @ 2012-04-01 10:44 ` Paweł Sikora 2 siblings, 0 replies; 5+ messages in thread From: Paweł Sikora @ 2012-04-01 10:44 UTC (permalink / raw) To: Jan Kratochvil; +Cc: gdb 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 (...) ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-04-01 10:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-31 13:05 very slow gdb stepping Paweł Sikora 2012-03-31 21:57 ` Jan Kratochvil 2012-03-31 22:01 ` Jan Kratochvil 2012-04-01 9:19 ` Paweł Sikora 2012-04-01 10:44 ` Paweł Sikora
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).