Bug 14002 - big cpu/mem hog on large c++ applications.
Summary: big cpu/mem hog on large c++ applications.
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: 7.4
: P2 critical
Target Milestone: ---
Assignee: dje
Depends on:
Reported: 2012-04-20 14:40 UTC by Pawel Sikora
Modified: 2012-11-13 22:40 UTC (History)
4 users (show)

See Also:
Host: x86_64-gnu-linux
Target: x86_64-gnu-linux
Build: x86_64-gnu-linux
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Pawel Sikora 2012-04-20 14:40:31 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

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:
Comment 1 Pawel Sikora 2012-04-24 19:59:47 UTC
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.
Comment 2 Pawel Sikora 2012-04-28 16:51:28 UTC
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.
Comment 3 dje 2012-11-13 22:40:50 UTC
This should be fixed now.
Please reopen if not.