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

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

> > Also, the double loop may prove to be slow for large number of children.
> 
> I was thinking that only a small number of children would ever exist
> simultaneously.  Scrolling might make that a larger number but maybe
> it could be arranged to delete children that go out of view.

You are right, we do that in DSF-GDB.  However, such a double loop can become
prohibitive relatively quickly, at numbers lower than when children start
being deleted.  For example, DSF-GDB allows for 1000 varObjs simultaneously,
before doing any deletion.  This may not prove too slow, but it creates
a requirement on the frontend to do proper management of varObjects, to
avoid any issues.  If we can avoid the double loop (and its string
comparisons), we would benefit, no?

> > I was thinking that we could keep order of children as they are defined
> > (current behaviour) but not fill them all, until requested.
> > We could create the full Vector of children as is done now by
> > 
> >   while (VEC_length (varobj_p, var->children) < var->num_children)
> >     VEC_safe_push (varobj_p, var->children, NULL);
> 
> I guess this would remove the need for a second loop but it seems wasteful on
> memory.  Previously children variable objects were stored as a linked list and,
> as I have said before, I do think this is more suitable as objects can then be
> inserted and removed at any point in the sequence of children.

Yes, linked list seem more suited for this usecase.  But I gather from Volodya's 
emails that vectors have benefits that we should not ignored, so let's continue 
the discussion with vectors.
To me, the advantage of your patch is far larger in the fact that we no longer
need to create all children varObj at once; my impression is that the memory allocation
is a small optimization in caparison.  Is that a correct impression?
Besides, currently, the memory is immediately allocated, so things wouldn't be 
any worse :-)

> > We can even improve on that by doing the following: instead of allocating
> > the vector for all children, we can allocate the vector for the children up
> > to start+number*stride.
> 
> The variables start, number and stride might be selectable by the user but I'm
> thinking that "number" used by Gdb will be controlled by how many elements are
> visible on the screen.  What happens with your approach when new elements
> become visible and new children need to be created?

Here is a simplified example.
Say you have an array of a 1000 integers and we can show 10 elements on the screen.
The user 'opens' the array, revealing the first 10 elements.  The user then jumps-scrolls
to position 500 revealing postions 500 to 509.  I imagine a set of commands to be
something like this:

-var-list-children -f 0 -n 10 var1
-var-list-children -f 500 -n 10 var1

The first call to var-list-children would allocate a vector of size (number+start = 0+10).
And create those 10 children varObjs.
The second call would expand that vector to a size of (number+start = 500+10).
And create those 10 children varObjs.
Positions 10 to 499 would remain NULL since we haven't create the children yet (and we may
never create them, if the user does not scroll there.)

Is that what you were asking?

Marc