This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
symtab/1731: Looking up symbols is extremely slow - find_pc_sect_section needs to be optimized
- From: aaronw at net dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 2 Aug 2004 22:26:22 -0000
- Subject: symtab/1731: Looking up symbols is extremely slow - find_pc_sect_section needs to be optimized
- Reply-to: aaronw at net dot com
>Number: 1731
>Category: symtab
>Synopsis: Looking up symbols is extremely slow - find_pc_sect_section needs to be optimized
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Aug 02 22:28:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: aaronw@net.com
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
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 would make lookups take log(n) time instead of n^2.
This is particularly noticable when attempting to debug KDE applications.
>How-To-Repeat:
Start up gdb and attempt to step through a large application.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: