From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6887 invoked by alias); 6 Oct 2004 20:06:43 -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 6846 invoked from network); 6 Oct 2004 20:06:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 6 Oct 2004 20:06:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CFI3U-0004Rb-Kv; Wed, 06 Oct 2004 16:06:32 -0400 Date: Wed, 06 Oct 2004 20:52:00 -0000 From: Daniel Jacobowitz To: Jan Hubicka Cc: Jeffrey A Law , gcc@gcc.gnu.org, amacleod@redhat.com Subject: Re: Varray memory consumption strikes back Message-ID: <20041006200632.GA16973@nevyn.them.org> Mail-Followup-To: Jan Hubicka , Jeffrey A Law , gcc@gcc.gnu.org, amacleod@redhat.com References: <20040904095915.GV1947@kam.mff.cuni.cz> <1094317419.2919.9.camel@localhost.localdomain> <20040904213324.GI15137@kam.mff.cuni.cz> <1095137295.10968.305.camel@localhost.localdomain> <20040914151414.GU10129@kam.mff.cuni.cz> <1095352487.10968.1594.camel@localhost.localdomain> <20040916220328.GZ3692@kam.mff.cuni.cz> <1095911109.11715.44.camel@localhost.localdomain> <20041006195934.GW10273@kam.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041006195934.GW10273@kam.mff.cuni.cz> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00231.txt.bz2 On Wed, Oct 06, 2004 at 09:59:34PM +0200, Jan Hubicka wrote: > > On Thu, 2004-09-16 at 16:03, Jan Hubicka wrote: > > > > > Using obstacks for these is obviously cheaper than varrays so it might > > > be nice incremental step. What I was thinking of is to simply wrap > > > obstack with something like OBSTACK_PUSH_TREE / OBSTACK_POP_TREE so the > > > api is more symetric to what varrays has that I think is much more > > > readable. > > I'm not 100% convinced that obstacks are cheaper than what we're > > doing. But there's a way to be 100% sure, try them. I've tried > > to decipher their behavior to determine if they could be efficiently > > used for similar tasks, but frankly got lost in the code. > > > > > > > In the case you like this idea, I can simply do that once you are > > > finished with the current thread of removing nested arrays. > > You can certainly try it and see what results you get. I'd be > > most interested in the compile time behavior as well as memory > > utilization. > > Hi, > > unfortunately obstack won't allow you to pop data ; to my surprise ;) Eh? obstack_free is precisely a pop operation. > This is stack implementation that don't use resizing and ggc. I converted the > dom's stacks to it and it seems to be resonably fast. On Gerald's testcase it > redues compilation time from 1m14.581s to 1m14.025s (consistently) and memory > footprint from 89MB to 80. > > While measuring the bootstrap speed, the difference seems to be winthin noise. You didn't include the new files. -- Daniel Jacobowitz