Re: Performance issue of -var-list-children on structs with many members and remote targets

[Raphael Zulliger <zulliger@indel.ch>]

On 08/08/2014 12:31 PM, Yao Qi wrote:
> On 08/08/2014 03:25 PM, Raphael Zulliger wrote:
>> Now my simple question: Couldn't GDB be tweaked to get the struct member
>> values by just one call (because members within a struct are guaranteed
>> to be consecutive, aren't they?):
>>
>> 499,883 38-var-list-children var2.public
>> 499,884 &"Sending packet: $m601050,24#??"
>>
>> I guess this would dramatically increase overall performance.
>>
>> I would really like to see such an improvement in GDB. Therefore, I'd be
>> very happy to hear your thoughts and suggestion. Thinks like: What
>> problems (e.g. border cases) could arise when implementing this? Where
>> to start in the GDB code for such a modification? Or do there exist any
>> GDB switches to improve performance on such operations? etc...
> I have no idea how to merge multiple reads into one.
Thanks for your response!

I guess you are aware of the fact that -data-evaluate-expression is 
already getting the data in the most efficient way, see e.g.:

-data-evaluate-expression --thread 1 --frame 0 g_s
&"Sending packet: $m601050,18#2e..."
&"Packet received: 000000000000f03f00000000000000000000000000000000\n"
^done,value="{a = 1, b = 0, c = 0}"

Couldn't we do the same during a '-var-update' for a struct like varobj 
and let it propagate the values to it's children, instead of letting the 
children update their values?

An implementation could probably indeed be done with a cache system, as 
suggested by you below. Then the "only" changes would be to implement 
that cache and to update struct-like varobj *before* traversing their 
children. Would something like that make sense?
>
> Cache is used in GDB to read code and stack from target, which
> increases performance to some extent (See target_read_code and
> target_read_stack).  However, cache is NOT used to read general data.
> Probably, you can make general data reading use cache too.
In our use case, we're debugging real-time systems in which (global) 
data often changes at a rapid rate and thus the cache alone wouldn't 
help much.