From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15460 invoked by alias); 14 Sep 2004 15:41: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 15450 invoked from network); 14 Sep 2004 15:41:05 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org with SMTP; 14 Sep 2004 15:41:05 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 91E034B4103; Tue, 14 Sep 2004 17:41:04 +0200 (CEST) Date: Tue, 14 Sep 2004 15:54:00 -0000 From: Jan Hubicka To: Mark Mitchell Cc: law@redhat.com, gcc@gcc.gnu.org Subject: Re: GCC Status Report (2004-09-13) Message-ID: <20040914154104.GT378@atrey.karlin.mff.cuni.cz> References: <414627A4.4080109@codesourcery.com> <1095135012.10968.268.camel@localhost.localdomain> <41467AFA.3020200@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41467AFA.3020200@codesourcery.com> User-Agent: Mutt/1.5.6i X-SW-Source: 2004-09/txt/msg00860.txt.bz2 > 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. Honza