[m-rev.] for post-commit review: limit stack layout compression
pbone at csse.unimelb.edu.au
Wed Jul 27 13:55:14 AEST 2011
On Tue, May 24, 2011 at 07:13:05PM +1000, Zoltan Somogyi wrote:
> Add progress messages that say when the compiler is converting the
> information it gathered for the construction of layout structures
> into the actual layout structures. In some cases (such as zm_enums.m),
> these could take a very long time.
> Impose limits on how aggressive we want the compression of layout
> structures to be. This is because in the absence of those limits,
> the compression of the layout structures for zm_enums.m can literally
> take an hour.
> Implement a new option controlling the limit to be applied by
> Document the new option.
> More changes to allow this diff to be tested for its performance
> effects. With the default limit, the compiler compiles the 16 largest
> modules in a debug grade 10% faster, but generates .c files that total
> about 8.4% bigger. Both effects should be smaller for smaller modules;
> small modules won't see any change at all.
The patch looks fine.
However, I wonder if we can compress these structures even when they're large
by compressing only some part of them at a time. Say the limit is set to 1000,
and there are 2000 structures in a module. Compress the first 1000, then
compress the next 1000 separately. I'm not familiar enough with the problem to
be able to propose anything with any more detail.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: Digital signature
More information about the reviews