From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29329 invoked by alias); 18 Apr 2006 16:17:01 -0000 Received: (qmail 29062 invoked by uid 22791); 18 Apr 2006 16:17:00 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 18 Apr 2006 16:16:57 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FVsso-000459-Gu; Tue, 18 Apr 2006 12:16:54 -0400 Date: Tue, 18 Apr 2006 16:45:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI: performance of getting stack arguments Message-ID: <20060418161654.GA15524@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i 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-04/txt/msg00249.txt.bz2 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? If it's the arguments, we may be able to improve it. Maybe build a debuggable GDB and "maint set profile"? > 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? 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. -- Daniel Jacobowitz CodeSourcery