From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23404 invoked by alias); 19 Apr 2006 16:13:09 -0000 Received: (qmail 23393 invoked by uid 22791); 19 Apr 2006 16:13:08 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Apr 2006 16:13:05 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k3JGD3P7025832 for ; Wed, 19 Apr 2006 09:13:03 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay8.apple.com (Apple SCV relay) with ESMTP id C2B7C1C9 for ; Wed, 19 Apr 2006 09:13:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: <1CE7391B-7261-49BD-9068-89C201F555DE@apple.com> <444539D9.80805@adacore.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37D48AED-AF3A-46D4-84B5-DFC9E3FB9B08@apple.com> Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: performance of getting stack arguments Date: Thu, 20 Apr 2006 10:22:00 -0000 To: GDB List X-Mailer: Apple Mail (2.749.3) 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/msg00265.txt.bz2 On Apr 19, 2006, at 1:45 AM, Eli Zaretskii wrote: >> Cc: Vladimir Prus , gdb@sources.redhat.com >> From: Jim Ingham >> Date: Tue, 18 Apr 2006 14:17:24 -0700 >> >> But just keep in >> mind, when you are implementing a GUI debugger that anything you show >> in the UI you are pledging to update every time a step is completed. >> And most folks are pretty sensitive about how long it takes for each >> step to complete. So you do need to be a bit conservative about what >> you display by default. Adding to this, gdb does get slow as >> programs get large, which makes it even more important to be >> judicious. > > How about if we implement a facility to send just the changes in the > call stack since the last time the stack was sent? This way, the > amount of stuff sent each stop will be much smaller, I think. We have seldom found that it's the amount of data sent that is the bottle-neck. It's almost always gdb's processing that's too slow. For instance, in the case of the stack, we implemented a "stack-list- frames-lite" that uses gdb's unwinder to get the first couple of stack frames (which are the hard ones) and then uses a simple method that doesn't do unwinding, but just traces the stored pc & fp up the stack (which is easy because you know that there are no frameless functions in the way.) Using this (and then only letting gdb do the real stack backtrace when the stack has changed) made a noticeable improvement in step response times. Anyway, in the course of profiling all this stuff, we didn't find that the data handing was a significant part of the time spent. N.B. one of the points of Andrew's frame changes was to allow the platform unwinders to have a quick unwind if only the fp & pc were requested, and then do the full unwind if anything else was requested. That way just the simple stack would be fast, and anything more would bring in prologue parsing, etc. It's been on my to-do list to try to get this to work for a while, but I haven't found the time to do it yet. Jim