From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12826 invoked by alias); 30 Apr 2008 07:09:43 -0000 Received: (qmail 12651 invoked by uid 22791); 30 Apr 2008 07:09:41 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Apr 2008 07:09:23 +0000 Received: (qmail 8913 invoked from network); 30 Apr 2008 07:09:19 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Apr 2008 07:09:19 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Wed, 30 Apr 2008 09:39:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <18456.6496.685993.987138@kahikatea.snap.net.nz> In-Reply-To: <18456.6496.685993.987138@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804301109.20906.vladimir@codesourcery.com> 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/msg00686.txt.bz2 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