From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7787 invoked by alias); 21 Feb 2006 06:52:12 -0000 Received: (qmail 7771 invoked by uid 22791); 21 Feb 2006 06:52:12 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Feb 2006 06:52:10 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FBRNS-0007O4-Ce for gdb@sources.redhat.com; Tue, 21 Feb 2006 09:52:07 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FBRNK-0007MS-5o; Tue, 21 Feb 2006 09:51:54 +0300 From: Vladimir Prus To: Jim Ingham Subject: Re: MI: type prefixes for values Date: Tue, 21 Feb 2006 14:15:00 -0000 User-Agent: KMail/1.7.2 Cc: GDB List References: <200602171724.03824.ghost@cs.msu.su> <200602201026.15624.ghost@cs.msu.su> <01627BAA-38C7-4391-A344-54B23B5F1863@apple.com> In-Reply-To: <01627BAA-38C7-4391-A344-54B23B5F1863@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602210951.53705.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00279.txt.bz2 On Monday 20 February 2006 21:58, Jim Ingham wrote: > Making variable objects is always slower than just printing the > values if you are only doing it one time. The variable objects don't > do any magic to get their values - they go through the same code as > "print" does ultimately, but they do a little more work getting > there. The overhead is not all that great, however. Just malloc'ing > some data structures and inserting them into a list somewhere. > > The advantage of variable objects is that they cache the parsed > expression. So the second & third etc. evaluation is much faster. > This is a pretty common usage pattern, especially with local > variables, since you usually step a number of times in any given > frame, and the locals all have to be updated with each step. The > variable objects have some other convenient features, like the -var- > update command which refreshes the values will report only the > variable objects whose values have changed, so the front end has to > fetch less data. Say, I've created a bunch of variable objects for for local variables. When I leave the function, those variables become invalid. How do you detect this case? Do you have a command '-list-var-objects-that-are-dead', or some other mechanism. > We also added the option to return all the locals in all the blocks > in a function. This allows you to present all the variables, and > then mark the ones which are not currently in scope appropriately. I > find this less confusing than having the contents of the variables > window come and go as you step through the function. Most of our > users seem to agree. Heck, such a feature will immediately fix: http://bugs.kde.org/show_bug.cgi?id=120439 Is this patch available on some branch in the public CVS repository? - Volodya