From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1284 invoked by alias); 5 Feb 2002 01:13:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1212 invoked from network); 5 Feb 2002 01:13:13 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 5 Feb 2002 01:13:13 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5F1EC3E55; Mon, 4 Feb 2002 20:13:13 -0500 (EST) Message-ID: <3C5F31A8.9060502@cygnus.com> Date: Mon, 04 Feb 2002 17:13:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Berlin Cc: Jim Blandy , Petr Sorfa , Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00095.txt.bz2 > > > Here's a question to think about as we move towards that: > Where should the cache be? > > If you are using oft-computed expressions, we should be able to cache them > if the information they depend on hasn't changed. > > Should each thing that implements the functions above handle caching > internally, or should we put it one level above, and add functions to make > generic queries like "is this location going to change if the x > register changes". > > Assuming the queries are cheap, you could simply walk the changed > values in the frame, ask if if any matter, and if not, you don't need > to redo the calculation/value. Relatively speaking I'd expect it to be cheap. The most common case of something changing is when the target is resumed. For this case, GDB has to invalidate everything and start again from scratch. Hence, this is the case GDB needs to have working fast. Initially, at least, register and memory writes can just be treated like target resumes - target-changd. Supporting this is varobj (well what I understand of it) Varobj tracks variables identifying those that changed. It then provides a refresh list to the UI (Insight or MI). While the computation necessary to identify changed variables is singificant, it is nothing when compared to the overhead of refreshing a variable's value on the screen. By avoiding unnecessary refreshes, performance is significantly improved. The other thing is that GDB has plenty of easier fixes when it comes to caching: not flushing the cache when switching threads; pre-fetching memory; .... Anyway, as they say, get it working, then get it working fast; A slow program shipped today is still quicker than a fast program shipped tomorrow; ... :-^ -- Jim, to throw a question in here. Where does this overall change leave $frame? I'm suspecting that the existing frame code ends up being pushed sideways and down covered by a new layer that lets you get at the above. enjoy, Andrew