From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3474 invoked by alias); 20 Jan 2004 15:29:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3443 invoked from network); 20 Jan 2004 15:29:21 -0000 Received: from unknown (HELO bellatrix.tat.physik.uni-tuebingen.de) (134.2.170.113) by sources.redhat.com with SMTP; 20 Jan 2004 15:29:21 -0000 Received: by bellatrix.tat.physik.uni-tuebingen.de (Postfix, from userid 30023) id D52FDFF46; Tue, 20 Jan 2004 16:29:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by bellatrix.tat.physik.uni-tuebingen.de (Postfix) with ESMTP id B517682E3; Tue, 20 Jan 2004 16:29:19 +0100 (CET) Date: Tue, 20 Jan 2004 15:29:00 -0000 From: Richard Guenther To: Jan Hubicka Cc: gcc@gcc.gnu.org, Mark Mitchell Subject: Re: Speed/profile of gcc3.4 In-Reply-To: Message-ID: References: <20040120133546.GD21361@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-01/txt/msg01510.txt.bz2 On Tue, 20 Jan 2004, Richard Guenther wrote: > On Tue, 20 Jan 2004, Jan Hubicka wrote: > > > > Hi! > > > > > > To give some more data to the speed of g++ discussion I built a profiling > > > compiler and ran it over the tramp3d.cpp testcase > > > (http://www.tat.physik.uni-tuebingen.de/~rguenth/gcc/tramp3d.cpp.gz). Top > > > on the (flat) profile are > > > > > > % cumulative self self total > > > time seconds seconds calls s/call s/call name > > > 7.85 24.64 24.64 71506294 0.00 0.00 ggc_alloc > > > 3.37 35.23 10.59 75978109 0.00 0.00 htab_find_slot_with_hash > > > 3.17 45.20 9.97 15526171 0.00 0.00 walk_tree > > > > Actually I did some profiling of this too and at least from Gerald's > > testcase I concluded that wast majority of the hashtable uses come from > > the for_each_template_parm. Jason mentioned that Mark plans to trim > > down use of these. That should make it possible to shot this function > > out of profiles completely. > > > > Mark, do you made some progress on this? If not, I can try to do > > something myself if you give me someguidelines. Btw. - looking at walk_tree_without_duplicates and the associated walk_tree in tree-inline.c - we're putting all visited trees in the hashtab. Can't we avoid putting trees inside there that can't be shared? Maybe at least optimize this in the for_each_template_param case? Just a thought, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/