From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7103 invoked by alias); 8 Jan 2003 01:50:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7069 invoked from network); 8 Jan 2003 01:50:50 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 8 Jan 2003 01:50:50 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18W7FL-00077s-00; Tue, 07 Jan 2003 21:51:15 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18W5Mu-0008CV-00; Tue, 07 Jan 2003 20:50:56 -0500 Date: Wed, 08 Jan 2003 01:50:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: oprofile; Was: [RFA] Kill some linear searches in minsyms.c Message-ID: <20030108015056.GA31507@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20030106042203.GA28848@nevyn.them.org> <3E19EEED.6070605@redhat.com> <20030107222402.GB20617@nevyn.them.org> <3E1B6DDF.2010405@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1B6DDF.2010405@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00314.txt.bz2 On Tue, Jan 07, 2003 at 07:16:31PM -0500, Andrew Cagney wrote: > >On Mon, Jan 06, 2003 at 04:02:37PM -0500, Andrew Cagney wrote: > > > >>>Future things to examine: > > > >> > >>Now this reminds me. > >> > >>Things-to-do-today includes run oprofile on GDB while debugging > >>something like mozilla. That would give a real picture of where GDB is > >>spending its time. > > > > > >I have a couple more similar patches for the places we're spending our > >time :) After I clear up some more backlog. > > Based on profile or oprofile? > > The problem with profile is that it artifically inflates the call > frequency of small functions and that leasily leads to mis-analysis. > cf, not so recently where the a finger was pointed at the pid/tid > functions as the cause of thread slowness. The real problem was (and > probably still is) too many system calls. Some of each; this batch is mostly gprof. For functions with a large per instance time, this is plenty accurate. It also gives exact call counts, which are useful for the accessors even when they're not really the problem; e.g. the 27M calls to symbol_demangled_name that I could tell didn't belong there. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer