gdb/457: GDB runs slow (internal doco needed) (FAQ)

[ac131313 at redhat dot com]

>Number:         457
>Category:       gdb
>Synopsis:       GDB runs slow (internal doco needed) (FAQ)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 04 06:08:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     ac131313@redhat.com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
It is thought that three area's dominate the debuggers performance:

- symbol table loading during startup
The time/memory required to load the symbol tables.

- step/continue performance
This dominates interactive performance.  It just isn't worth worrying about things like the user modifying target memory.  This includes things like inferior function calls and single stepping.  Most of the problem is in the number of system (ptrace) calls required to extract the information from the kernel.  GDB also does dumb things like discard all this state at random points.

- GUI refresh

Related to the above.  Being able to identify just the information that changed so that GUI refresh operations are limited to areas that need an update.  See varobj.[ch].

If profiling GDB to improve performance it is important to look beyond the raw numbers (some one line pid/tid functions come up as ``hot spots'') and more at the overall picture (the thread_info object should be used).  Replacing apparently hot functions with macros isn't an option.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: