From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16924 invoked by alias); 23 Sep 2004 03:45:14 -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 16917 invoked from network); 23 Sep 2004 03:45:13 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 23 Sep 2004 03:45:13 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8N3jDFf017252; Wed, 22 Sep 2004 23:45:13 -0400 Received: from [172.16.83.126] (vpn83-126.boston.redhat.com [172.16.83.126]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8N3jBr12549; Wed, 22 Sep 2004 23:45:12 -0400 Subject: Re: Varray memory consumption strikes back From: Jeffrey A Law Reply-To: law@redhat.com To: Jan Hubicka Cc: gcc@gcc.gnu.org, amacleod@redhat.com In-Reply-To: <20040916220328.GZ3692@kam.mff.cuni.cz> 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> Content-Type: text/plain Organization: Red Hat, Inc Message-Id: <1095911109.11715.44.camel@localhost.localdomain> Mime-Version: 1.0 Date: Thu, 23 Sep 2004 11:38:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg01331.txt.bz2 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. jeff