From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7875 invoked by alias); 19 Apr 2006 08:28:54 -0000 Received: (qmail 7864 invoked by uid 22791); 19 Apr 2006 08:28:52 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Apr 2006 08:28:47 +0000 Received: from farnswood.snap.net.nz (p202-124-114-192.snap.net.nz [202.124.114.192]) by viper.snap.net.nz (Postfix) with ESMTP id 3B282753C64; Wed, 19 Apr 2006 20:28:44 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id 2997562A99; Wed, 19 Apr 2006 09:28:35 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17477.62642.286957.5130@farnswood.snap.net.nz> Date: Wed, 19 Apr 2006 09:02:00 -0000 To: Eli Zaretskii Cc: jingham@apple.com, dewar@adacore.com, ghost@cs.msu.su, gdb@sources.redhat.com Subject: Re: MI: performance of getting stack arguments In-Reply-To: References: <1CE7391B-7261-49BD-9068-89C201F555DE@apple.com> <444539D9.80805@adacore.com> <17477.23561.267057.180@farnswood.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.0.50.38 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/msg00261.txt.bz2 > > I agree. The requirements are different: with CLI the user will generally > > type bt at a specific point in the session, while with MI the command > > "-stack-list-frames" gets sent every time the UI needs to update. > > These are not _requirements_, these are _use_cases_. The requirements > are the same: to be fast enough for most uses. E.g., nothing prevents > me from including "bt" in the commands list of a breakpoint, which > would force GDB to produce the backtrace on each stop. Whatever you want to call them I think, in practice, such commands will generally be issued more frequently with a UI than from the command line. Improving the response time can be tackled at two ends of course: not only making the command run more quickly but also running it less frequently. For example, using event notification to tell the UI when the current frame has changed. Currently for Emacs I request a new stack after each user command, which is clearly inefficient. -- Nick http://www.inet.net.nz/~nickrob