From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14542 invoked by alias); 12 May 2009 08:25:43 -0000 Received: (qmail 14519 invoked by uid 22791); 12 May 2009 08:25:39 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 May 2009 08:25:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 67EED2BAC01; Tue, 12 May 2009 04:25:32 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gwKOIpcn79FL; Tue, 12 May 2009 04:25:32 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 175C02BABE3; Tue, 12 May 2009 04:25:32 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 74728F5905; Tue, 12 May 2009 10:25:30 +0200 (CEST) Date: Tue, 12 May 2009 08:25:00 -0000 From: Joel Brobecker To: Paul Pluzhnikov Cc: gdb-patches@sourceware.org, Tom Tromey Subject: Re: [patch] Eliminate quadratic slow-down on number of solibs (part 2). Message-ID: <20090512082530.GD7584@adacore.com> References: <8ac60eac0905051749p3b5d14d9q8903b9de8e18137f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0905051749p3b5d14d9q8903b9de8e18137f@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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 X-SW-Source: 2009-05/txt/msg00238.txt.bz2 > Even after the two patches above, there is still some repeated > and unnecessary setting and resetting of the breakpoints as each > solib is added :-( > > Attached is an alternative patch which subsumes the other two, > and kills additional 15% of wasted CPU time. > > It feels like a hack, but I don't see how to achieve the same > result in a cleaner way :-( I haven't had a chance to look at the other patch, but, yeah, it does feel like a hack! :-/. But I'm sympathetic to the issue - it's tough to have to wait an extra 20secs when you know that you don't have any breakpoint refering to any SO... My thoughts on this: Perhaps a setting in the "maintenance set/show" that the user could change to deactivate breakpoint reset. The default is the current behavior, but if the user knows what he's doing, he can change it. Not sure what the other maintainers think about that. Horrible, but better than nothing. That being said, I still think we should try to do as good a job as we can automatically, so your first suggestion should also be incorporated. -- Joel