From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3690 invoked by alias); 1 May 2008 18:14:41 -0000 Received: (qmail 3679 invoked by uid 22791); 1 May 2008 18:14:39 -0000 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 18:14:18 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m41IEExF019571; Thu, 1 May 2008 13:14:14 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 13:14:14 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH:MI] Return a subset of a variable object's children Date: Thu, 01 May 2008 18:14:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BD10@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA042910B6@ecamlmw720.eamcs.ericsson.se> <200805011954.31277.vladimir@codesourcery.com> From: "Marc Khouzam" To: "Vladimir Prus" Cc: "Nick Roberts" , X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00015.txt.bz2 > > In DSF-GDB, we have a LeastRecentlyUsed queue which allows us to know w= hich > > varObj is the oldest (which implies it is not visible), and we can dele= ted > > once we have reached our limit of 1000 varObjs. >=20 > What is the practical measured advantage of that? I never took the time to measure the impact of this limit at different leve= ls. 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.=20=20 >=20 > There's no concept of 'old varobjs' in MI protocol. You should delete var= iable > 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 cac= hing. 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= =20 > implementing the 'variables' widget -- that shows local variables of a > function, expressions that user wishes to be always visible, and some aux= illary > values.=20 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 c= onsidered. > I can think about those: >=20 > 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 unt= il 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. >=20 > 2. "Subset". Probably, there's some local subset of array elements that t= he user > wants to look at. I think in that case, we should have a way to create on= ly 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 o= f an array? -var-create - * myArray@10=20 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 e= ach 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 struct= s 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 e= lement. > 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 me= mory view, > is quite adequate. >=20 > What I don't see as a valid use case is one where: >=20 > 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-ch= ildren 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 t= he 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 i= s all we need for dealing with a large array? Marc