From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25562 invoked by alias); 16 Mar 2008 02:24:06 -0000 Received: (qmail 25543 invoked by uid 22791); 16 Mar 2008 02:24:05 -0000 X-Spam-Check-By: sourceware.org Received: from nikam-dmz.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 16 Mar 2008 02:23:48 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 29025) id 1AAC81536D8; Sun, 16 Mar 2008 03:23:46 +0100 (CET) Date: Sun, 16 Mar 2008 03:41:00 -0000 From: Zdenek Dvorak To: Richard Guenther Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH][RFC] Statistics "infrastructure" Message-ID: <20080316022345.GA14678@kam.mff.cuni.cz> References: <20080315230529.GA25593@kam.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i 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/msg00960.txt.bz2 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)? Zdenek