From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13116 invoked by alias); 19 Apr 2006 06:20:39 -0000 Received: (qmail 13104 invoked by uid 22791); 19 Apr 2006 06:20:38 -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; Wed, 19 Apr 2006 06:20:33 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FW637-0000Jj-3Q for gdb@sources.redhat.com; Wed, 19 Apr 2006 10:20:30 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FW62q-0000G2-Dn; Wed, 19 Apr 2006 10:20:08 +0400 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: MI: performance of getting stack arguments Date: Wed, 19 Apr 2006 07:55:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <20060418161654.GA15524@nevyn.them.org> In-Reply-To: <20060418161654.GA15524@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604191020.08044.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-04/txt/msg00258.txt.bz2 On Tuesday 18 April 2006 20:16, Daniel Jacobowitz wrote: > On Tue, Apr 18, 2006 at 08:10:34PM +0400, Vladimir Prus wrote: > > Hi, > > I've run into a performance problem with "-stack-list-arguments 1" > > command. I issue the command in order to obtain stack arguments for all > > frames, and I've 129 frames. Each frame has just a couple of arguments. > > However, the command execution takes 608 ms. > > > > If this command is issued repeatedly, the time is roughly the same. > > > > 1. Any ideas why the command takes so long? > > It's reading a lot of memory, probably. Is it really the arguments, > rather than the backtrace, causing the delay? It's specifically the -stack-list-arguments command that takes 600ms. The separately issued -stack-list-frames takes 150ms which is not fast either, but not as bad as -stack-list-arguments. > If it's the arguments, > we may be able to improve it. Maybe build a debuggable GDB and "maint > set profile"? Sure. What's the right way to build debuggable GDB, setting CFLAGS=-g during configure or something else? > > 2. Any ideas what should I do to to avoid making user wait half-a-second > > on each "step"? I can try to reload stack only when current frame id > > changes. But then, each time I enter a new function, there's still that > > half-a-second delay. > > Probably only some of these are visible; you could just do the visible > ones? I though about it and it might work, assuming that "-stack-list-arguments 1 100 110" won't take too much time to get to frame 100. I think getting to frame 100 should be fast, since nothing should be printed, but will need to check. > Or, eventually, you could do what Xcode does and get stack IDs > from GDB, and assume that arguments haven't changed on step in. I find > that a bit shady though, given how likely it is that their "apparent" > values will change. Since the primary use of arguments in stack windows (IMO) is to spot "suspicious" values first time you stop, it might be not necessary to update arguments at each step. Only after "continue"/stop. - Volodya