From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12950 invoked by alias); 26 Mar 2013 14:55:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12670 invoked by uid 89); 26 Mar 2013 14:55:31 -0000 X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 26 Mar 2013 14:55:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2QEtRfw002184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Mar 2013 10:55:27 -0400 Received: from localhost.localdomain (ovpn-116-94.ams2.redhat.com [10.36.116.94]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2QEtQId006164; Tue, 26 Mar 2013 10:55:27 -0400 Message-ID: <5151B6DE.80703@redhat.com> Date: Tue, 26 Mar 2013 17:17:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Tom Tromey CC: "gdb-patches@sourceware.org" Subject: Re: [patch][python] 1 of 5 - Frame filter Python C code changes. References: <513E56EC.2050802@redhat.com> <87vc8kzd5d.fsf@fleche.redhat.com> In-Reply-To: <87vc8kzd5d.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-03/txt/msg00968.txt.bz2 On 21/03/13 20:55, Tom Tromey wrote: > > On irc you mentioned that performance wasn't great. > I'm wondering if you are working on the frame stash fix. > I think it would be good for that to go in first, so that there isn't a > window where frame filter performance is bad. Frame printing is about 20% slower, and that is really only noticeable on backtraces of 10,000 frames or more. Frame filtering and application of decorators is instant. So performance is comparable in all but the most demanding of situations. I think a frame stash using a hash table is doable, but I think it is overkill because I am extremely suspicious of the frame to frame object code. As we get the older() and newer() frames we invalidate the frame stash. The reason for getting the two nearest older and newer frames is dubious in the extreme. A frame will always have a frame level - that is GDB assigned. Even completely busted inferior frames, will be properly encapsulated in a GDB frame, and, have a level assigned. The only other scenario I can think of for the logic is if GDB itself has encountered corruption in the call stack and this is to preserve the last place. But at that point why are we hiding that from the user? Things are likely going to fail, and fail badly, soon. My proposal is just to use the existing find_frame_by_id function and not bother with this other stuff. That will stop invalidating the frame stash and likely solve the performance issue. Cheers, Phil