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

[Vladimir Prus <vladimir@codesourcery.com>]

On Wednesday 30 April 2008 11:01:52 Nick Roberts wrote:
>  > >  > > step size (stride) other than one.
>  > >  > 
>  > >  > I'm not sure what the stride would be used for.  Maybe something like
>  > >  > printing all even indexes of an array for example?  In any case, it is
>  > >  > a pretty simple addition, and no one is forced to use it, so I'm only
>  > >  > asking to understand better.
>  > > 
>  > > Yes, I think its just another way to sample a large array.  ISTR dbx allows
>  > > printing array slices in this way.
>  > 
>  > And is this behaviour particularly useful?
> 
> It depends on your point of view.  In scientific computing (my background),
> arrays are often used and sampling allows the data to be viewed at a lower
> resolution for an overall picture of a value set.

...

>  > primary goal of incremental fetch is that if you happen to have std::vector
>  > with 200 children, then display of it won't fill your entire screen with
>  > children of a single variable.  With incremental fetch, you can look at the
>  > children only if you're really interested.  On the other hand, I don't think
>  > keeping 200 varobjs in GDB is too expensive. And if we talk about 10000
>  > children, then well, I don't think standard variable display widget is gonna
>  > be very good. Even if you delete varobjs that are not visible, it's too hard
>  > to find anything interesting among 10000 elements.
> 
> Again in scientific computing, arrays often have many more than 10000 elements.
> In image processing arrays are two dimensional 512x512 with over 250,0000
> elements.  The user would have to identify the region of interest for the
> display widget, e.g. [110:120][220:230] for a 10x10 square centred at
> (115,225).

It seems to me that specialized widgets are more suitable for this purpose, like
image viewer, or a charting component. Especially with image data, using varobjs
is probably not going to work. Creating varobjs per each item will be just too slow --
we need some high-bandwidth interaction way, like the memory-reading commands.
(And maybe those should have stride options).

>  > >  > 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.
>  > 
>  > Please feel free to implement generic list datastructure in C, or rewrite
>  > gdb in C++.  So far, using vector proved to be big convenience.
> 
> Clearly I'm not going to do either but we could simply go back to using the
> linked list structures that were already in varobj.c.  It's a question of 
> whether the convenience outweighs the handicap of having to work with vectors
> all the time or not.  IMHO it doesn't.

I disagree, and I haven't yet seen a practical "handicap". We're not going back
to hand-written data structures for MI implementation.

>  > >  > but only actually create the children that have been requested by the
>  > >  > user.  I'm not sure how much efficiency there is by allocating the
>  > >  > memory before hand?  Also, is there no way to grow the vector by more
>  > >  > than a single point at a time?
>  > > 
>  > > Like resize with STL vectors?  I'm not aware of one.
>  > 
>  > VEC_safe_grow
> 
> OK, I didn't know about that.  Why not use it instead of VEC_safe_push in the
> construct above?

Well, it happens not to initialize the data, so some changes in further logic will
be required. Until now, it was not a performance issue.

- Volodya