This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thursday 01 May 2008 22:14:12 Marc Khouzam wrote:
> 
> > > 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.

What does it mean "no longer being showed". If you have a variables tree,
and some variable is in the tree, but is not visible on the screen right now,
there's no need whatsoever to delete the variable object for that variable.
If that variable is huge structure, then updating it (inside GDB) on each
step, can take some time, especially on a slow remote target. But, I think
you send -var-update once per each visible variable, so this is not an issue
for you.

If a variable is deleted from variables tree (because you left the scope
where that variable is defined), then you should delete variable object.
There's no reliable way to detect that exactly same variable is in scope
again and must be shown, so no reuse is possible.

Honestly, except for the fact that -var-update reads target memory, I'm sure
that GDB can create more variable objects that SWT can create TreeItems :-)

> 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.

I'm still not sure what you mean -- you mean that a variable object is not shown
in any widget, but only is stored in the cache? What is the key of the cache?

> > 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 

I don't know :-) I think that myArray@10 is gdb CLI trick; I never though it could
be used in MI, but thinking of it, I cannot see a reason why not.

> 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.

Well, then, the problem is in *your* code :-) If GDB has no problem creating
variables objects for all children, but your cache fills up, then you have wrong
size of a cache. Honestly, I suspect the best way would be just to remove the
caching, but I need to know exactly what is the key of the cache is.

> 
> > 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.

Yes, this is my "Oops" use case -- we should create some reasonable number of children
initially, and incrementally fetch more per user request, thereby giving the user a
chance to stop :-)

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

I don't know. It means that if you want to get more children, you have to delete variable
object, and create new one and list children. It seems that -var-list-children V 10-20
is easier -- if -var-list-children can do this, then for example, incremental children
fetch in KDevelop will be implemented in a single line of code.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]