From: Daniel Jacobowitz <drow@mvista.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sources.redhat.com
Subject: Re: gdb/457: GDB runs slow (internal doco needed) (FAQ)
Date: Thu, 04 Apr 2002 10:49:00 -0000 [thread overview]
Message-ID: <20020404134949.A3989@nevyn.them.org> (raw)
In-Reply-To: <1020404184426.ZM28992@localhost.localdomain>
On Thu, Apr 04, 2002 at 11:44:27AM -0700, Kevin Buettner wrote:
> 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)?
I was just thinking the same thing :)
> --- 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
No, it's simpler than that. You define the functions in headers as
'static inline'. I think that works quite far back along the train of
C history.
Now, I could easily check what difference it made if the profile
patches had ever made it into GDB...
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
prev parent reply other threads:[~2002-04-04 18:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020404165802.6629.qmail@sources.redhat.com>
2002-04-04 9:47 ` Andrew Cagney
2002-04-04 10:44 ` Kevin Buettner
2002-04-04 10:49 ` Daniel Jacobowitz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020404134949.A3989@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
--cc=kevinb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox