From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20781 invoked by alias); 17 Jun 2005 19:48:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20766 invoked by uid 22791); 17 Jun 2005 19:48:26 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 17 Jun 2005 19:48:26 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5HJmNmN023900 for ; Fri, 17 Jun 2005 12:48:23 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 17 Jun 2005 12:47:07 -0700 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j5HJl7jP006374; Fri, 17 Jun 2005 12:47:07 -0700 (PDT) In-Reply-To: <17074.31377.996795.526839@farnswood.snap.net.nz> References: <17072.62436.183299.55978@farnswood.snap.net.nz> <50B12BF2-9C7D-43ED-AF21-D1EA42AC7115@apple.com> <17074.1440.40908.588287@farnswood.snap.net.nz> <412387CD-8F52-46E0-865F-560543C1E757@apple.com> <17074.31377.996795.526839@farnswood.snap.net.nz> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CF840F7-0F6B-4A57-B4DE-A277A643826D@apple.com> Cc: gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jason Molenda Subject: Re: [PATCH] -stack-select-frame Date: Fri, 17 Jun 2005 19:48:00 -0000 To: Nick Roberts X-SW-Source: 2005-06/txt/msg00260.txt.bz2 On Jun 17, 2005, at 12:24 AM, Nick Roberts wrote: >> (one of the parts of this profiling which is especially useful is >> that we have a "mi-timings-enabled" setting. When it's enabled, >> every MI command reports how long gdb took to complete it, e.g. the >> "time=" bit at the end here: >> >> -> 50-stack-list-frames 0 5 >> <- 50^done,stack=[frame= >> {level="0",addr="0x0009e7fc",fp="0xbfffe700",func=" [...] ,frame= >> {level="5",addr="0x936265d0",fp="0xbfffeee0",func="-[NSApplication >> run]"}],time= >> {wallclock="0.14353",user="0.00584",system="0.00335",start="111895234 >> 8.0 >> 03847",end="1118952348.147372"} >> > > Yes but what happens when the stack is much deeper, 20 or 30 say, > like it can > be when you you are debugging Emacs, or GDB for that matter? Yes, stack crawling is slow, and stacks 30-50 frames deep are not at all unusual in GUI heavy-call-back applications like we have on MacOS X. When we've worked on optimizing performance on something like a user pressing the "Next" button, -stack-list-frames is a serious problem. We implemented a command, "-stack-list-frames-lite" here at Apple. It crawls the stack (there's a -limit option to specify how many frames to crawl) and shows the pc + fp for each frame. A "stop at a breakpoint and press next a few times" scenario looks like -thread-list-ids -stack-list-frames-lite -limit 500 -stack-list-frames 0 7 (I had eight frames at this point) -stack-select-frame 0 -stack-list-arguments 2 0 0 -stack-list-locals 2 1 -file-list-statics -file "*CURRENT FRAME*" -shlib "" "--no-values" - filter "^_OBJC" -constants 0 -exec-next -thread-list-ids -stack-list-frames-lite -limit 500 -stack-select-frame 0 -stack-list-frames 0 0 -var-update "var1" "var2" "var3" -exec-next and so on. So we only do the (expensive) -stack-list-frames the first time we enter a function. But the point I originally was trying to make is that the overhead of issuing MI commands is really, really, really low on MacOS X. For instance, -stack-list-frames 0 0 took 0.00039 seconds wallclock to return its information in a quick test I just did. -stack-list- frames-lite with 8 frames took 0.01422 seconds. -var-update with three varobjs took 0.00493 seconds. Yeah, I happen to be using a really fast G5 system right now, but we do all of our performance timings on slower boxes (currently around the 1GHz range) and my own personal goal is to keep the time it takes for a "Next" button press to finish should be no more than 0.2 seconds, and it should be a *reliable* amount of time. Users get into a rhythm of pressing "Next" and if it takes much longer than 0.2 seconds, or if it takes different amounts of time, they get grumpy. Oops, I'm off topic again. MI commands fast. It's not going to cause me any problems if you add more output to existing commands, but we've seen little benefit in trying to combine discrete commands here at Apple. J