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

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

[Andrew Cagney]

[mailing list changed]
>> 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.

As for accessor functions and an opaque type - I see only benefits.  It 
forces discussion when adding new accessor methods or techniques; it 
allows the internals to be re-written; it stops people grubbing around 
where they shouldn't; and it removes the need for constant vigalnce by 
the maintainer - checking that someone isn't bit rotting the code by 
adding a grub.

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

Look at the STREQ() hack.  A micro optomization that tried to hide a 
more global (bad algorithms) problem.

I'm pretty sure that there is the same situtation here - there is a 
problem with how GDB represents this info internally.  If the general 
case really is:

		thread (with a frame)
	 
	  N:M
	light-weight-process (with a regcace)

Then perhaps GDB's internal data structures should reflect this - an 
abstract ``struct thread_info'' with a frame.  A more concrete ``struct 
lwp_info'' with hard registers.

Andrew

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

[Kevin Buettner]

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

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

[Daniel Jacobowitz]

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