From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29707 invoked by alias); 30 Apr 2008 14:03:09 -0000 Received: (qmail 29683 invoked by uid 22791); 30 Apr 2008 14:03:04 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Apr 2008 14:02:38 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m3UE2XTx030554; Wed, 30 Apr 2008 09:02:34 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 09:02:34 -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: Wed, 30 Apr 2008 14:59:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA042910B5@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <18455.41299.899430.615138@kahikatea.snap.net.nz> From: "Marc Khouzam" To: "Nick Roberts" Cc: 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-04/txt/msg00701.txt.bz2 > > Also, the double loop may prove to be slow for large number of children. >=20 > 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 beco= me 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 > >=20 > > while (VEC_length (varobj_p, var->children) < var->num_children) > > VEC_safe_push (varobj_p, var->children, NULL); >=20 > I guess this would remove the need for a second loop but it seems wastefu= l on > memory. Previously children variable objects were stored as a linked lis= t and, > as I have said before, I do think this is more suitable as objects can th= en 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 Volo= dya's=20 emails that vectors have benefits that we should not ignored, so let's cont= inue=20 the discussion with vectors. To me, the advantage of your patch is far larger in the fact that we no lon= ger need to create all children varObj at once; my impression is that the memor= y allocation is a small optimization in caparison. Is that a correct impression? Besides, currently, the memory is immediately allocated, so things wouldn't= be=20 any worse :-) > > We can even improve on that by doing the following: instead of allocati= ng > > the vector for all children, we can allocate the vector for the childre= n up > > to start+number*stride. >=20 > The variables start, number and stride might be selectable by the user bu= t I'm > thinking that "number" used by Gdb will be controlled by how many element= s 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 =3D 0+10). And create those 10 children varObjs. The second call would expand that vector to a size of (number+start =3D 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