From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16627 invoked by alias); 19 Jul 2012 19:23:58 -0000 Received: (qmail 16614 invoked by uid 22791); 19 Jul 2012 19:23:57 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-fa0-f73.google.com (HELO mail-fa0-f73.google.com) (209.85.161.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Jul 2012 19:23:44 +0000 Received: by fahx12 with SMTP id x12so161164fah.0 for ; Thu, 19 Jul 2012 12:23:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:content-type:content-transfer-encoding:message-id:date :to:cc:subject:in-reply-to:references:x-mailer:from :x-gm-message-state; bh=a6aQPfDsqAV+3q10k0EE51MWWEZHtzbh2KTw8vFnoaw=; b=F5D23PgGnMg4x5hnWmq3g7IJMZP8Sljn33qo3WCFclipQuaMFT9Th7Y9FBbstT8Ktu IoRSY5AhTIf4uQ3cBHlfEZdlnsdAC59/YRe1wX0AqCauqBpvrFhKXsaLFOtQEi3xDeqk T3Ix6CbVzvF1mxnDZwUpu7ZOrYGeYjVTh7t8YxLiTiTPqITXRmLRaVysce0Z6YGxvs4C 9sWjh3xfnbvzsfxDa3qokGB1DKaVWUbz4fsJ4e60O4rNJoIsRODoqZDD2tSsUnQhA5is /X2YBCEGcGvhVrNFKS9QBABoKJPgXrCt38kJHzkl00/rYbhINhsDsJpgr3Zhx/brEOyg P45g== Received: by 10.180.14.169 with SMTP id q9mr1446943wic.0.1342725822875; Thu, 19 Jul 2012 12:23:42 -0700 (PDT) Received: by 10.180.14.169 with SMTP id q9mr1446936wic.0.1342725822829; Thu, 19 Jul 2012 12:23:42 -0700 (PDT) Received: from hpza9.eem.corp.google.com ([74.125.121.33]) by gmr-mx.google.com with ESMTPS id 46si3835051eed.1.2012.07.19.12.23.42 (version=TLSv1/SSLv3 cipher=AES128-SHA); Thu, 19 Jul 2012 12:23:42 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com (ruffy2.mtv.corp.google.com [172.18.110.129]) by hpza9.eem.corp.google.com (Postfix) with ESMTP id 6BD475C0050; Thu, 19 Jul 2012 12:23:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20488.24252.142398.372836@ruffy2.mtv.corp.google.com> Date: Thu, 19 Jul 2012 19:23:00 -0000 To: Gary Benson Cc: gdb-patches@sourceware.org, saugustine@google.com Subject: Re: [RFA 5/4 take 2] Improved linker-debugger interface In-Reply-To: <20120719151913.GF25093@redhat.com> References: <20120719151913.GF25093@redhat.com> From: dje@google.com X-Gm-Message-State: ALoCoQn3tjFFRx6e+Mu2/wdJLV9X8gnL83PtYb36NPjiZ3X4GCTTjDjM5KREtw68PQsCAwAwIalWXEraxx4mMvX6XsO0lHcsL4X3VB/DAXa59E4umvd/K0bDLrRrNpNFSGt5Wd6AeLEcHhRJFjJ1oYHKPKdM+f/Ba8vqyUyn7O8TAcHOhBoD9mBmG68pSkfIsVlHgU1YQ+z9 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: 2012-07/txt/msg00373.txt.bz2 Gary Benson writes: > Hi all, > > I did some profiling and realised that the probes patch I just mailed > had reintroduced calls to update_section_map, a slow function I did > some work to avoid calling last year: > > http://www.cygwin.com/ml/gdb-patches/2011-07/msg00460.html > http://www.cygwin.com/ml/gdb-patches/2011-10/msg00361.html > > Attached is a patch to avoid calling update_section_map from the > probes interface. Updated timings are as follows: > > no of solibs 100 250 500 1000 2000 5000 > ------------------------------------------------------------ > old interface 1 3 9 35 141 942 > new interface 0 0 1 4 14 89 > (times in seconds) > > So, with this patch GDB is not three but ten times faster. Cool. Not that you have to write it, but if you've got the beginnings of something already :-), gdb should have a performance testsuite. It needn't run it with "make check" since it could quite expectedly increase the time to run the normal testsuite beyond a reasonable threshold. But we should start collecting testcases to exercise gdb's performance, and one nice way to do this is to have testcase generators. I wouldn't want to manually write 5000 shared libs :-), but I do want to track gdb's performance of handling that much over time, and it's rather straightforward to write a program that will generate a specified number of shared libs. [And similarly for other performance issues we want to track.] The result of such a testsuite needn't be PASS/FAIL, per se. As a start it just needs to report numbers. [Comparing absolute performance depends on the machine used to run the test, etc. etc. etc. I think these are solvable problems, and I think this is something we need to do.] Thoughts?