This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH:MI] Return a subset of a variable object's children
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