From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12811 invoked by alias); 20 Jul 2011 13:17:29 -0000 Received: (qmail 12792 invoked by uid 22791); 20 Jul 2011 13:17:28 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from gbenson.demon.co.uk (HELO gbenson.demon.co.uk) (80.177.220.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Jul 2011 13:17:08 +0000 Date: Wed, 20 Jul 2011 13:56:00 -0000 From: Gary Benson To: Paul Pluzhnikov Cc: gdb-patches@sourceware.org Subject: Re: [RFC][patch] Avoid repeated calls to solib_add on initial attach. Message-ID: <20110720131705.GA32570@redhat.com> Mail-Followup-To: Paul Pluzhnikov , gdb-patches@sourceware.org References: <20110715205209.8B3B3190BC2@elbrus2.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110715205209.8B3B3190BC2@elbrus2.mtv.corp.google.com> X-IsSubscribed: yes 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: 2011-07/txt/msg00519.txt.bz2 Paul Pluzhnikov wrote: > Following up on my earlier "slow on high-latency links" message: > http://sourceware.org/ml/gdb-patches/2011-07/msg00391.html ... > > Attached patch avoids calling solib_add twice when initially attaching > inferior. > > I am not entirely happy about this patch, but don't have a better > idea for a fix, and do want to avoid repeated rescans of the shared > library list. > > (Some of our executables use 4000+ shared libraries, and the time in > solib_add does add up.) > > Tested on Linux/x86_64, no regressions. > > Comments? I've had a look at this and aside from the typo noted below it seems fine. I didn't see any speedup on the 1000 library testcase I've been using for my own stuff (the bulk of the time seemed to be printing all the "Loaded symbols for X.so" and "Reading symbols from X.so" messages) but maybe this is because I'm running everything locally and possibly you are not? In any event, the second solib_add call was skipped as expected. > made all the inferior hook methods consistent, this call could be > removed. Call it only after the solib target has been initialized by > - solib_create_inferior_hook. */ > + solib_create_inferior_hook. Only do this if not alreay done from ^^^^^^ Typo Cheers, Gary -- http://gbenson.net/