RE: -var-update @

["Marc Khouzam" <marc.khouzam@ericsson.com>]

> > For DSF, which tries to minimize the amount of work done, we can:
> > 
> > 1- use multiple var-update <singleVarObj>, which typically results in 
> > about 5 or 6 var-updates being sent (only 5 or 6 variables are 
> > visible on-screen). Then GDB on the target reads the memory for 
> > those 5 or 6 varObjs.
> > 
> > 2- use var-update *, which results in a single -var-update, but which
> > makes GDB on the target read the memory of all varObjects, which can be
> > anywhere from, say, 5 to 5000, or even more.
> > 
> > As you can see, option 2 does not scale, irrespective of which is 
> > the true bottleneck, the round-trip time, or the target memory access.
> 
> You can freeze variable objects that are not visible to the user,
> and -var-update * won't fetch those. Please see the -var-set-frozen
> command.

I handn't thought of that.  Although, this also comes with its own drawbacks.
If the user scrolls the variable view, new varObjects will need to be updated,
but they will need to be unfrozen first, and the newly hidden ones will
need to be frozen.  In the end, I think it will end up being more commands
than using var-update <varObj>.

With DSF updating only visible varObjs, I think var-update <varObj> is 
sufficiently efficient.

Marc