Re: symtab/1731: Looking up symbols is extremely slow - find_pc_sect_sectionneeds to be optimized

[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