From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10753 invoked by alias); 16 Mar 2008 08:58:39 -0000 Received: (qmail 10737 invoked by uid 22791); 16 Mar 2008 08:58:38 -0000 X-Spam-Check-By: sourceware.org Received: from ns.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 16 Mar 2008 08:58:18 +0000 Received: from Relay2.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 2FE4934C45; Sun, 16 Mar 2008 09:58:16 +0100 (CET) Date: Sun, 16 Mar 2008 09:33:00 -0000 From: Richard Guenther To: Zdenek Dvorak Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH][RFC] Statistics "infrastructure" In-Reply-To: <20080316022345.GA14678@kam.mff.cuni.cz> Message-ID: References: <20080315230529.GA25593@kam.mff.cuni.cz> <20080316022345.GA14678@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00965.txt.bz2 On Sun, 16 Mar 2008, Zdenek Dvorak wrote: > Hi, > > > > > A statistics event consists of a function (optional), a statement > > > > (optional) and the counter ID. I converted the counters from > > > > tree-ssa-propagate.c as an example, instead of > > > > > > > > prop_stats.num_copy_prop++; > > > > > > > > you now write > > > > > > > > statistics_add ("copy propagations"); > > > > > > > > (function and statement omitted, you might prefer #defines for strings > > > > that you use multiple times). > > > > > > it would perhaps be better to use #defines with integer values? Also, > > > it would be more consistent to have statistics.def similar to > > > timevar.def for this. It would make creation of new counters a bit > > > more difficult, but on the other hand, it would make it possible to > > > classify the counters (by type of the counted operation/its > > > expensiveness/...), > > > > The difficultness to add new counters is exactly why I didn't go > > down that route. I expect this mainly used for experimentation > > where it is IMHO inconvenient to go the .def route > > I thought of it more as an aid in debugging performance problems, as in, > checking the dumps without introducing new statistics counters; in which > case, having some description of what the counters mean and the metadata > from the .def file would be useful. > > On the other hand, I agree that for the purpose that you suggest > avoiding .def is better. Perhaps we could require that all the > statistics strings are #defined and documented (and of course you can > ignore this rule for the counters that you use for experimentation)? Sure, we can even do a .def file for this purpose. Richard.