Varray memory consumption strikes back

[Daniel Jacobowitz]

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