This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

symtab/1731: Looking up symbols is extremely slow - find_pc_sect_section needs to be optimized


>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:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]