Re: [cdt-debug-dev] Really Fixing Arrays

[Chris Songer <songer@xxxxxxxxxxxxx>]

> It is on my todo for the head.

Great! I look forward not to our not having to make the same changes when 
we update!

When you are considering this on the head, there is an area where you can 
further affect user perception of speed. The array fetching with [] syntax 
is fast enough so that while range may be "better", the end user experience 
is not going to change much.

However, stepping through frames with big arrays is still slowed -- even 
when those arrays are not opened. (hence no new -var-creates have been issued!)

The problem is that GDB slows once you do a -var-create on a 16k array. You 
don't even have to get the children for every GDB interaction to slow down! 
The variable being there causes the problem. The next user perceivable 
problem to fix here is getting the total array size without having to do 
that var create on the top level array.

It used to be that the size of the array was determined by the number of 
returns from -var-list-children! That's one of the things that we had to 
fix since fetching everything to determine the number of bins is clearly 
unacceptable. Now that information comes from the string that comes back 
from -var-eval-expr on the 16k variable. The remaining  problem is that 
creating that variable slows GDB on all subsequent operations. It's 
livable, but annoying.

If anyone has any fast and easy ideas on that, I'd love to hear them.

Thanks!
-Chris