hi, 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 commit 7bd518fd9738c50a5197af2b184acd97e4d4df40 Author: Tom Tromey <tromey@redhat.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: http://sourceware.org/ml/gdb/2012-03/msg00096.html
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 9728 /* core project sources */ $ find sources -type f -name '*.h' -o -name '*.c' -o -name '*.?pp' |wc -l 7488 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.