From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20249 invoked by alias); 14 Sep 2004 15:44:06 -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 20241 invoked from network); 14 Sep 2004 15:44:05 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.10) by sourceware.org with SMTP; 14 Sep 2004 15:44:05 -0000 Received: (qmail 11264 invoked from network); 14 Sep 2004 15:44:04 -0000 Received: from localhost (HELO ?192.168.0.105?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 14 Sep 2004 15:44:04 -0000 Message-ID: <414711BE.30408@codesourcery.com> Date: Tue, 14 Sep 2004 17:07:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: Jan Hubicka CC: law@redhat.com, gcc@gcc.gnu.org Subject: Re: GCC Status Report (2004-09-13) References: <414627A4.4080109@codesourcery.com> <1095135012.10968.268.camel@localhost.localdomain> <41467AFA.3020200@codesourcery.com> <20040914154104.GT378@atrey.karlin.mff.cuni.cz> In-Reply-To: <20040914154104.GT378@atrey.karlin.mff.cuni.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00862.txt.bz2 Jan Hubicka wrote: >>Jeffrey A Law wrote: >> >> >> >>>On Mon, 2004-09-13 at 17:05, Mark Mitchell wrote: >>> >>>September 19 >>> >>> >>>* General compile-time performance improvements [Weinberg] >>> >>>Q. Presumably we can still also attack memory consumption >>> issues as well. Right? >>> >>>The reason I ask is I have the first in what I expect will >>>be a series of patches to start reducing memory consumption >>>and bring more sense to our data structures. >>> >>> >>> >>> >>Yes. We have a pretty good sense that reducing memory usage correlates >>with reducing compile time, and, of course, people do not infinite RAM >>anyhow, so this is a resource we should use prudently. The biggest >>caveat is the one you have been raising recently: that touching pages >>merely for the purpose of marking memory as free is by no means always a >>win. But, if you can make data structures smaller in the first place, >>and just allocate less along the way, that's going to help. >> >>So, yes, this is OK -- but please do use your judgement about the >>prudence of attempting major overhauls. The smaller the change (whether >>in terms of lines of code or in terms of conceptual complexity) the >>better, naturally. >> >> > >Thanks. >Just for a record - we consume roughly 4 times as much memory as 3.4 did >for common C sources. Even tought we are down from 7 times we did week >ago, this is still major regression. > I definitely agree. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com