From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15895 invoked by alias); 16 May 2013 18:44:32 -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 15884 invoked by uid 89); 16 May 2013 18:44:31 -0000 X-Spam-SWARE-Status: No, score=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MISSING_HEADERS,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_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; Thu, 16 May 2013 18:44:31 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4GIiUWl031276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 May 2013 14:44:30 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4GIiSlj028154; Thu, 16 May 2013 14:44:29 -0400 Message-ID: <5195290C.1020403@redhat.com> Date: Thu, 16 May 2013 18:44:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 CC: Phil Muldoon , "gdb-patches@sourceware.org" Subject: Re: [patch] Convert frame_stash to a hash table References: <5194DA88.6020705@redhat.com> <5194E257.4010807@redhat.com> <5194E424.9090605@redhat.com> <5194EBEF.9040209@redhat.com> In-Reply-To: <5194EBEF.9040209@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00641.txt.bz2 On 05/16/2013 03:23 PM, Pedro Alves wrote: > I'd expected that a simple filter (like I imagine yours was) > you'd not see any performance hit. For the archives -- Phil and I spent a bit investigating tihs. This expectation was just too naive. The way the current frame stash is managed today (the last frame get_frame_id is called on) lends itself to all sorts of random places in the frame code where the stash happens to flip to the wrong frame, or cases where we'd expect the stash to be set but isn't (e.g., frapy_older leaves without the stash set to the older frame). This is just too fragile for this use case. Let's move on with the new hash stash and be done with it. Thanks, -- Pedro Alves