Sourceware Bugzilla – Bug 14002
big cpu/mem hog on large c++ applications.
Last modified: 2012-11-13 22:40:50 UTC
i have a large c++ application (2.9GB of shared objects, 600MB of static
archives used in shared objects). on isolated part of sources a single
'next' call takes ~3 minutes and increases memory usage from ~500M to ~3G
while previous gdb-7.3.1 needs only 2..3 seconds and increases memory usage
from ~400M to ~550MB.
7bd518fd9738c50a5197af2b184acd97e4d4df40 is the first bad commit
Author: Tom Tromey <email@example.com>
Date: Mon Jul 11 17:17:25 2011 +0000
* dwarf2read.c (handle_DW_AT_stmt_list): New function.
(read_file_scope, read_type_unit_scope): Use it.
link to gdb mailinglist discussion:
current git/master (2e523a5f18498a902d55ae293cb3870d060f6a6b) is also affected.
here's quick info about project:
/* buildenv: boost + other libs */
$ find buildenv -type f -name '*.h' -o -name '*.c' -o -name '*.?pp' |wc -l
/* core project sources */
$ find sources -type f -name '*.h' -o -name '*.c' -o -name '*.?pp' |wc -l
so, there's ~17k sources which may be recorded in dwarf-4 (-g2) debuginfo.
for the tested slow-step-place, callgrind shows ~921k start_subfile() calls
and ~520M filename_cmp() calls (from start_subfile). so, i think that linear
scanning of subfile list and multiple deduce_language_from_filename
have non-trivial performance impact.
i've rebuilt the whole project with -fno-debug-type-sections (gcc-4.7)
and 7.4/master works as fast as 7.3.1 now. so, it looks like a serious
performance problem with .debug_types handling.
This should be fixed now.
Please reopen if not.