Re: -var-update @

[Michael Snyder <msnyder@specifix.com>]

On Thu, 2008-04-03 at 14:58 -0400, Daniel Jacobowitz wrote:
> On Fri, Mar 28, 2008 at 08:58:09AM +1200, Nick Roberts wrote:
> >  > DSF only updates varObj that are visible on screen.  So currently, it always
> >  > uses -var-update with a single varObj name (never use *).
> > 
> > Which must mean that there is a round trip to the target for each variable
> > object that needs to be updated.
> > 
> > This is sounds similar to the previous discussion about using
> > "-var-list-children --all-values".  There Daniel stated that "for a lot of
> > embedded targets [...] reading memory becomes the dominant time delay".
> > 
> > Can someone give some typical numbers for "round trip time" vs "reading memory"
> > time.  In my naive understanding of embedded targets, I would have thought the
> > "round trip time" might be large due to a slow serial link, while "reading
> > memory" wouldn't change much as all RAM is pretty much the same.  Or is the
> > latter slow because of the time taken to transfer any unneeded extra data back
> > to the host?
> 
> Reading memory from the target is usually, in my experience, dominated
> by round trip time.  There's at least three different round trips
> involved: MI frontend to GDB, GDB to debug server, debug server over
> hardware probe to the target.  Because GDB and the remote protocol
> are synchronous, only one memory read can happen at a time, so the
> first two always have to wait at least the length of the last one.
> A typical USB probe takes between 3ms and 10ms to read memory; that's
> just how USB works.  I've seen reports that on Windows's USB stack
> it's more like 50ms but I haven't confirmed that myself yet.
> 
> For typical use this delay is independent of the amount of memory
> you're reading, until it gets very large.  Four bytes and four hundred
> take about the same time.

Only if gdb requests it all in one go.
Sometimes it reads it a word at a time...
in that case all those round trips can really add up!