This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: symtab/1731: Looking up symbols is extremely slow - find_pc_sect_sectionneeds to be optimized
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 5 Aug 2004 17:38:01 -0000
- Subject: Re: symtab/1731: Looking up symbols is extremely slow - find_pc_sect_sectionneeds to be optimized
- Reply-to: Andrew Cagney <ac131313 at redhat dot com>
The following reply was made to PR symtab/1731; it has been noted by GNATS.
From: Andrew Cagney <ac131313@redhat.com>
To: gdb-gnats@sources.redhat.com
Cc:
Subject: Re: symtab/1731: Looking up symbols is extremely slow - find_pc_sect_section
needs to be optimized
Date: Thu, 05 Aug 2004 13:36:12 -0400
> When using gdb on a project with a large number of symbols and/or object files, performance becomes unusably slow. Probing the stack while gdb is running shows that the bottleneck is in find_pc_sect_section. This code walks through a linked list of object files, and then walks through each section searching for a match. Wouldn't it be faster if a separate data structure of just sections were maintained and that datastructure were sorted or stored in a binary tree based on the section address? This wo uld make lookups take log(n) time instead of n^2.
Hello,
Just some more general questions so we can better appreciate the
situtation that leads to this problem:
- how are you using GDB?
Can you describe what you're doing (commands or sequences) that you're
finding very slow. Also some rough numbers on things like #shlibs,
#symbols, and the m/c's speed.
- how is GDB using find_pc_sect_section
would it be possible for you to capture a list of calls to
find_pc_sect_section so that we can see how GDB is interacting with the
symbol table.
Andrew