RE: [PATCH:MI] Return a subset of a variable object's children

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

> > In DSF-GDB, we have a LeastRecentlyUsed queue which allows us to know which
> > varObj is the oldest (which implies it is not visible), and we can deleted
> > once we have reached our limit of 1000 varObjs.
> 
> What is the practical measured advantage of that?

I never took the time to measure the impact of this limit at different levels.
The idea is that we didn't know how many varObj GDB could handle without
loosing performance, so we chose 1000.

> > I still think that GDB should avoid having the requirement of 'deleting
> > old varObjs' toward the frontend.  
> 
> There's no concept of 'old varobjs' in MI protocol. You should delete variable
> objects as soon as whatever GUI thing you have no longer need to display the
> date the varobj corresponds to.

DSF-GDB tries to be as efficient as possible by avoiding request that go
to the backend.  Therefore, although a varObj is no longer being showed, we want
to keep it around in case it will be showed again.  Effectively, we are caching.
And our cache size is 1000 varObj.

I would appreciate your expertise on this.

> Let's clarify what varobjs are for, in my opinion. They are primarily for 
> implementing the 'variables' widget -- that shows local variables of a
> function, expressions that user wishes to be always visible, and some auxillary
> values. 

Yes, that is exactly when we use them: variables view, expressions view.

> There are natural scalability bounds in the UI -- if there are no
> arrays involved, and you try to show 1000 items (backed by 1000 variable objects),
> the UI is already useless. GDB is not the problem here.

Right, but for us the 1000 varObj are not meant to all be displayed at once
but are a caching system.

> Speaking about arrays, I also don't understand which use cases are been considered.
> I can think about those:
> 
> 1. "Oops". User, without much though, opens an item in variable tree. The
> item happens to be array of 10000 elements. We don't want UI to block until those
> elements are fetched -- we want to show a few (say 10) and allow the user to get
> some more in case he really wanted to see something.
> 
> 2. "Subset". Probably, there's some local subset of array elements that the user
> wants to look at. I think in that case, we should have a way to create only children
> in the range that user is interested in. And I think Nick's patch is just fine.

Now that I think about it, isn't there a mechanism to -var-create a slice of an array?
-var-create - * myArray@10 
The frontend would then manage multiple varObjs representing the slices of an array.
The CDT does that.
DSF does not do that because Pawel came up with a simpler idea (and because I wasn't
aware of the slice thing at the time; no doc on that slice thing, right?):
for arrays, we do not use -var-list-children, but instead, we -var-create each child
ourselves, when needed.

So, in our case, we have managed to work around large arrays.
However, I saw Nick's proposal as valuable because it applies to all structs and not
just arrays.  Also, it avoids the frontend having to have special logic for arrays.

> 3. "Data analysis". User actually wants to make some sense of all 10000 element.
> Maybe, well, draw a chart. Or just look at the data. The data is integer, or some
> other atomic type. Then, either some specialized widget, or merely the memory view,
> is quite adequate.
> 
> What I don't see as a valid use case is one where:
> 
> 1. The size of array is too large to keep all varobj always created.

I'm not sure what you mean here.  Before Nick's patch, issuing -var-list-children
on a large array would create a lot of varObjs.  In our case, it would have
filled up our varObj cache, although we would only be showing very few of the
array elements.

> 2. User would like to just scroll though all the array items, without
> clear intentions.

This is probably not a valid use case... although user behavior, even when dumb :-)
should not break the frontend.

But you got me thinking now... Maybe var-create using with an array slice is all we
need for dealing with a large array?

Marc