From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30967 invoked by alias); 2 Sep 2009 11:43:15 -0000 Received: (qmail 30950 invoked by uid 22791); 2 Sep 2009 11:43:14 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Sep 2009 11:43:06 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id A947410DCE; Wed, 2 Sep 2009 11:43:04 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 7959B10D18; Wed, 2 Sep 2009 11:43:04 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MioEx-00081u-6z; Wed, 02 Sep 2009 07:43:03 -0400 Date: Wed, 02 Sep 2009 11:43:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: More info on PR/9711 (quadratic slowdown for deep stack traces) Message-ID: <20090902114303.GA30223@caradoc.them.org> Mail-Followup-To: Joel Brobecker , gdb@sourceware.org References: <20090901204815.GK4379@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090901204815.GK4379@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00015.txt.bz2 On Tue, Sep 01, 2009 at 01:48:15PM -0700, Joel Brobecker wrote: > One improvement I'm looking at is the fact that get_prev_frame is > doing redundant checks when the previous frame has already been > computed. So I'm currently testing the idea of adding: > > if (this_frame->prev_p) > return this_frame->prev; > > (before doing the various checks and then calling get_prev_frame_1). > Does anyone see why this would be a problem? It does not change the This almost, almost works. I can see two problems: * Can the results of those checks ever change? For instance, does "set backtrace past-main off" flush the stack frame? If not, it won't take effect right away after this change. * There are places that call get_prev_frame_1 directly. So one frame past main may be in the chain, but we usually don't want it. Now, the results of the checks could be cached in the frame object... > There might be some other micro optimizations that we could do, > I haven't looked further. But to break the quadratic behavior, > I suspect we need to avoid the call to frame_find_by_id, which means > that we would net to have prev_register routine return the frame in > addition to the value - I think that we would have to be very careful > with what we do with the frame. Have frame_find_by_id keep a cache with the same lifetime as current_frame. If it saves the last frame it returned, we can try that frame and the previous frame before going on to searching from the current frame. Also, have frame_find_by_id use get_prev_frame_1? I'm not sure why we don't. You'd have to look at the callers, but I can't see the problem. -- Daniel Jacobowitz CodeSourcery