From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24980 invoked by alias); 16 May 2013 18:53:20 -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 24969 invoked by uid 89); 16 May 2013 18:53:20 -0000 X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED autolearn=ham version=3.3.1 Received: from gbenson.demon.co.uk (HELO blade.nx) (80.177.220.214) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 16 May 2013 18:53:14 +0000 Received: by blade.nx (Postfix, from userid 500) id 3E963263C9B; Thu, 16 May 2013 19:53:11 +0100 (BST) Date: Thu, 16 May 2013 18:53:00 -0000 From: Gary Benson To: gdb-patches@sourceware.org Subject: Re: [RFA 0/7] Improved linker-debugger interface Message-ID: <20130516185311.GA22794@blade.nx> Mail-Followup-To: gdb-patches@sourceware.org References: <20130516144340.GA2105@blade.nx> <87fvxmzv62.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fvxmzv62.fsf@fleche.redhat.com> X-SW-Source: 2013-05/txt/msg00643.txt.bz2 Tom Tromey wrote: > >>>>> "Gary" == Gary Benson writes: > Gary> A quick and dirty speed comparison yielded the following results: > > Gary> no of solibs 128 256 512 1024 2048 4096 > Gary> -------------------------------------------------------------- > Gary> old interface 0 1 4 12 47 185 > Gary> new interface 0 0 2 4 10 36 > Gary> (time in seconds) > > I know we discussed this before, but I don't recall the outcome. > > It still looks like there is a non-linearity in there. Do you know > why? Some of it is certainly because GDB stores solibs in linked lists. There is a little bit of introduced quadratic behaviour in this patch because target_so_ops->current_sos() is expected to return a freshly allocated list of libraries to update_solib_list(), which either adds them to its own list or frees them if it already has them. This makes sense for the standard interface, which reads everything from the inferior into a list and returns it. The probes interface already has a list built by the time target_so_ops->current_sos() is called, but it has to create a copy to return. I spent some time trying to get around this in July or August last year but I hit a wall. I may have another look at this tomorrow, as this latest patch is very different in that area from what I was working with back then. > It would be good to have a bug for this. I will file one (tomorrow!) Thanks, Gary -- http://gbenson.net/