From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17259 invoked by alias); 4 Apr 2002 18:44:44 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17239 invoked from network); 4 Apr 2002 18:44:40 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 4 Apr 2002 18:44:40 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA08098; Thu, 4 Apr 2002 10:44:38 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g34IiRD28993; Thu, 4 Apr 2002 11:44:27 -0700 Date: Thu, 04 Apr 2002 10:44:00 -0000 From: Kevin Buettner Message-Id: <1020404184426.ZM28992@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: gdb/457: GDB runs slow (internal doco needed) (FAQ)" (Apr 4, 12:47pm) References: <20020404165802.6629.qmail@sources.redhat.com> <3CAC91A0.3000702@cygnus.com> To: Andrew Cagney , Daniel Jacobowitz Subject: Re: gdb/457: GDB runs slow (internal doco needed) (FAQ) Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00061.txt.bz2 On Apr 4, 12:47pm, Andrew Cagney wrote: > >> 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... > > I'll be ok with macro's when you can step into them, print their local > (macro) variables, ensure (using compiler warnings) that the user can't > grub a round directly in the object the macro is wrapping, not have any > side effects, not have pass by name problems, .... > Even static functions in headers are less evil than macros. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hmm... Jim Blandy recently added an autoconf test for ``inline'', right? I'm wondering if it'd be possible to define functions like ptid_get_pid() as being inline (in a header file like defs.h)? --- time passes --- I've done a bit more checking. It appears that autoconf defines ``inline'' as follows when it's not supported by the compiler: #define inline I think it might work if it were defined like this instead: #define inline static Kevin