From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3088 invoked by alias); 26 Jun 2006 20:57:21 -0000 Received: (qmail 3080 invoked by uid 22791); 26 Jun 2006 20:57:20 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Jun 2006 20:57:18 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5QKvGDW007728 for ; Mon, 26 Jun 2006 16:57:16 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5QKvG1P014972; Mon, 26 Jun 2006 16:57:16 -0400 Received: from [172.16.14.227] (IDENT:IhkP0XvhiX75Yn2YicFIALlyGNsoAXVO@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k5QKvGve020926; Mon, 26 Jun 2006 16:57:16 -0400 Message-ID: <44A04A2C.40807@redhat.com> Date: Mon, 26 Jun 2006 20:57:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: sid@sources.redhat.com Subject: Re: [patch][rfa] --gprof Performance Improvement References: <44A03979.2050108@redhat.com> <20060626195718.GB913@redhat.com> In-Reply-To: <20060626195718.GB913@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact sid-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00052.txt.bz2 Frank Ch. Eigler wrote: >Nicely done, thanks. (If backward compatibility was at all a concern, >the gprof component could have a new "sample" pin that assumes the >pin-based PC traffic, instead of changing the current interface. But >I agree that the old interface is not worth saving.) > >Was the string conversion stuff obvious in profiling output? > > I don't know --- I took a more brute force approach, since I knew that the overhead was in the driving of the cpu's sample-gprof pin (the only effect of using --gprof). I first suspected overhead in the std::map used to collect the buckets, but that turned out to be small. I then tried the "local reference for this->stats[current_stats]" optimization and got the 3%. I then tried experimentally removing the collection of the data and found no improvement. That left the parsing of the attributes which, when experimentally removed, accounted for all of the nasty overhead. Dave