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

[Daniel Jacobowitz <drow at mvista dot com>]

The following reply was made to PR gdb/457; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@mvista.com>
To: ac131313@redhat.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/457: GDB runs slow (internal doco needed) (FAQ)
Date: Thu, 4 Apr 2002 11:56:34 -0500

 On Thu, Apr 04, 2002 at 02:07:34PM -0000, ac131313@redhat.com wrote:
 > 
 > >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.
 
 - Slowdown of the running inferior
 
 For record, the worst offender here is lin-lwp.c stopping/starting all threads
 at every shared library breakpoint (may or may not be necessary) and at
 every thread creation/destruction (definitely not necessary).  I'm
 working on some code to cut this down.
 
 > - 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.
 
 If the thread_info object is used, we're still going to have all the
 little accessor functions.  Why the categorical objection to macros? 
 Especially in places that they would especially benefit compiler
 performance, like one-line accessor macros?  And even more so since GDB
 will soon support better macro debugging...
 
 ptid_get_pid () isn't going away, and by "coming up as ``hot spots''" I
 remember something like 10% _wall clock time_ in these little functions
 on some test cases.
 
 -- 
 Daniel Jacobowitz                           Carnegie Mellon University
 MontaVista Software                         Debian GNU/Linux Developer