RE: [dsdp-dd-dev] GDB/MI command enhancements

[Nick Roberts <nickrob@xxxxxxxxxxx>]

Hi Marc,

 > using the flags like --all-values might actually be a good idea.  However, I
 > would like to better understand the impact it will have on GDB.  Maybe you
 > can shed some light here.
 > 
 > When coding DSF we try to be as efficient as we can, so we try to avoid
 > requesting information from GDB, unless we really need it.  In the
 > -var-list-children example, when listing the children of a variable, such as
 > myArray[100], a view will only request the values of children that are
 > currently visible to the user (maybe myArray[0] through myArray[4]).  As the
 > user scrolls to see more elements, the view will request more information.

In Emacs, I think display is done at the C level rather than the Lisp level.
I don't think its possible to know at this higher level which lines are
displayed so I just ask the user if he/she wants to expand a node when there
are more than a given number of children (the default is 40).

 > For this reason, it maybe be better to rely on -var-evaluate-expression for
 > specific elements, instead of getting all values at once through
 > -var-list-children --all-values, when we may never need them.

Yes, I think this approach probably works best for very large arrays.  ISTR
that with Solaris dbx you could specify a range and step size for an array and
I think this is also true for Totalview where is can also be modified.  This
isn't possible with GDB although you can create artificial arrays like

-var-create - * a@len

where len is the number of elements that you want to display.

 >                                                               However, this
 > entirely depends on the way GDB handles such requests.  >From a GDB
 > point-of-view, how much slower is the response to -var-list-children if
 > --all-values is requested?  Especially in the case of a large list of
 > children.  Is it worth taking the hit up front, to later avoid calling
 > -var-evaluate-expression multiple times, or is it better to try to avoid
 > unnecessary requests and also stagger them over time?
 >  
 > Would you have an opinion about such performance aspects?

I've added an MI command (adapted from Apple GDB) described in th GDB manual:

     -enable-timings [yes | no]

   Toggle the printing of the wallclock, user and system times for an MI
command as a field in its output.  This command is to help frontend
developers optimize the performance of their code.  No argument is
equivalent to `yes'.

Doing:

-var-create - * m2
^done,name="var1",numchild="1000",value="[1000]",type="int [1000]"
(gdb) 
-var-create - * m2
^done,name="var2",numchild="1000",value="[1000]",type="int [1000]"
(gdb) 
-enable-timings yes
^done

I get:

(gdb) 
-var-list-children var1
...
time={wallclock="0.22846",user="0.17201",system="0.02000"}

(gdb) 
-var-list-children --all-values var2
...
time={wallclock="0.27797",user="0.21201",system="0.01600"}

So, in this case, most of the time appears to be taken creating the variable
objects rather than storing their value.

Using -var-evaluate-expression many times will require many transactions through
a pty but I don't know how to compute that overhead.

 > Finally, in some other situations, you are probably right that it would simply be better to use
 > the options available.  I'm thinking of -var-update <name> for example, where using the option --simple-values
 > may always be justified.  I will revisit the available options and see if any of them are obvious improvements.

ISTR that the output from "-var-update --simple-values" is the same as
"-var-update --all-values" (Emacs only uses the latter) because only leaf
variable objects ever get updated.  I added "--simple-values" for
-stack-list-locals only, but I was required to extend it to the other commands
by the GDB maintainers.


-- 
Nick                                           http://www.inet.net.nz/~nickrob