From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31077 invoked by alias); 20 Jan 2004 18:04:58 -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 31033 invoked from network); 20 Jan 2004 18:04:56 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sources.redhat.com with SMTP; 20 Jan 2004 18:04:56 -0000 Received: (qmail 26351 invoked from network); 20 Jan 2004 18:04:45 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 20 Jan 2004 18:04:45 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Tue, 20 Jan 2004 10:04:45 -0800 From: "Zack Weinberg" To: Jan Hubicka Cc: Nick Burrett , Gabriel Dos Reis , Marc Espie , geoffk@apple.com, gcc@gcc.gnu.org Subject: Re: gcc 3.5 integration branch proposal References: <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> <20040110154129.GA28152@disaster.jaj.com> <1073935323.3458.42.camel@minax.codesourcery.com> <1073951351.3458.162.camel@minax.codesourcery.com> <20040119013113.044D74895@quatramaran.ens.fr> <400BB40B.4070101@dsvr.net> <871xpvp9d7.fsf@egil.codesourcery.com> <20040120100839.GA21361@atrey.karlin.mff.cuni.cz> Date: Tue, 20 Jan 2004 18:04:00 -0000 In-Reply-To: <20040120100839.GA21361@atrey.karlin.mff.cuni.cz> (Jan Hubicka's message of "Tue, 20 Jan 2004 11:08:39 +0100") Message-ID: <87u12qo5s2.fsf@egil.codesourcery.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg01529.txt.bz2 Jan Hubicka writes: >> I am not sure why ggc_alloc comes in second; checking is disabled so > > My experience from oprofiling is, that ggc_alloc/garbage > collector/memset is where all our cache faults go, so they end up > high in profiles even when amount of work looks small. It is not > really ggc_alloc fault, rather it is the fact that we use too much > of it. True. One cause of excessive memset that I have wanted to address for years is, make_node() clears the entire tree node - but make_node is almost always called from somewhere that's going to fill in most or all of the fields anyway. We ought to have something like the gen_rtx_fmt_* functions for tree nodes. > I am working on some of these :) > One other major stopper you don't see on your profile is > for_each_template_parm that can eat about 10% when compiling Gerald's > application with optimizing. Oh, it's there even on this test case. It's down at #54 on the call graph, but it's responsible for two-thirds of the htab usage, which you can see at the top of the profile. zw