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

[Andrew Cagney <ac131313 at cygnus dot com>]

[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