This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Release RTL bodies after compilation (sometimes)


On Wed, 2004-09-15 at 13:50, Geoffrey Keating wrote:
> David Edelsohn <dje@watson.ibm.com> writes:
> 
> > 	Using lots of memory in an inefficient manner slows down the
> > compiler.  We should not turn the compile-time performance into a fixation
> > on reducing memory usage as a goal in isolation.
> 
> This is an important point.  I don't believe that freeing memory gives
> significant compile speed benefits except in unusual cases, and in
> general it slows the compile down because of the overhead of doing the
> freeing.
Agreed.


> When we speak of 'reducing memory usage' here at Apple, we do not mean
> 'allocating as much memory as before and then freeing it'.  We mean
> allocating less memory than before, and preferably doing this by
> allocating fewer objects rather than the same number of smaller ones.
Precisely.  Losing the block-local varrays is a great example; so
far it's consistently been better to go ahead and allocate a global
varray with markers to note where entries for the current block
end than anything I've seen with lazily allocating and recycling
those block local varrays.

I just finished the first cut at removing the block_defs local
varray in favor of a global one in tree-ssa-dom and tree-into-ssa.
To give you an idea we were creating 31594 block local varrays
for block defs (and that's allocating them lazily!).  Those
31594 block local varrays sucked up roughly 14M of memory.

With a global varray with block markers we generate 2132
varrays which suck up roughly 6M of memory.

Interestingly enough, this also allows us to remove the toplevel
block local data structure in tree-into-ssa.c.  Another 2000
varrays gone (unfortunately that savings is much smaller 200k).

[ All numbers are with Gerald's testcase. ]

Anyway, I just wanted to give a concrete example to illustrate
Geoff's point.

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]