From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10301 invoked by alias); 20 Feb 2006 18:57:31 -0000 Received: (qmail 10243 invoked by uid 22791); 20 Feb 2006 18:57:30 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Feb 2006 18:57:27 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k1KIvFgE009179; Mon, 20 Feb 2006 10:57:15 -0800 (PST) Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay6.apple.com (Apple SCV relay) with ESMTP id 8B7201AE; Mon, 20 Feb 2006 10:57:15 -0800 (PST) In-Reply-To: <200602201026.15624.ghost@cs.msu.su> References: <200602171724.03824.ghost@cs.msu.su> <20060217203120.GE30881@nevyn.them.org> <3D09ADF2-5A80-4B42-B4DE-2A2861C3A2AA@apple.com> <200602201026.15624.ghost@cs.msu.su> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01627BAA-38C7-4391-A344-54B23B5F1863@apple.com> Cc: GDB List Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: type prefixes for values Date: Mon, 20 Feb 2006 19:49:00 -0000 To: Vladimir Prus X-IsSubscribed: yes 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/msg00272.txt.bz2 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. It's been such a long time (~5 years) since we switched over to variable objects in ProjectBuilder (now Xcode) that I don't have any concrete numbers any more, sorry. BTW, one of the things we added on our side was an option to -stack- list-locals to make variable objects for all the locals it returns. This is very convenient. 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. Jim On Feb 19, 2006, at 11:26 PM, Vladimir Prus wrote: > On Friday 17 February 2006 23:40, Jim Ingham wrote: >> And... since the varobj's only parse the expression once when the >> varobj is created, getting the current values of varobj's is much >> faster than doing -data-evaluate-expression. Not a big deal if you >> are just printing one value. But if you are trying to update all the >> local variables on every step, this can be significant. People tend >> to be pretty sensitive to the speed of the "step" operation... > > Hi Jim, > > can you provide some concrete numbers? Specifically, is using > varobj to get > values of all local variables faster then a single -stack-list- > locals, and if > so, by how much? > > Thanks, > Volodya