Re: -var-update @

[Daniel Jacobowitz <drow@false.org>]

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.

-- 
Daniel Jacobowitz
CodeSourcery