[MLton] Re: [MLton-user] option ref optimized to a null pointer?

[Wesley W. Terpstra]

On Nov 24, 2007, at 10:07 PM, Vesa Karvonen wrote:
> If you run into cases where MLton is unable to optimize the
> representation as you'd expect, you should report it and maybe MLton
> can be improved to handle the case better.

Well, here's an example: (int ref * int ref * int ref) option array.
MLton doesn't flatten the refs into the tuple because the code  
elements of the array. So this representation takes 8+8+8+16 bytes on  
top of the 4 bytes for the array's pointer.
Contrast this to: (int ref * int ref * int ref) ref option array.
Here MLton is able to figure out that it can flatten the tuple to 16  
bytes plus the 4 byte (possibly null pointer) in the array. Less than  
half the memory is used.

In fact, this also happens outside of arrays. It seems that you can  
generally improve the representation MLton uses for (ref, ref, ref)  
tuples / records by adding another ref outside.

It's too bad there's no easy way to get MLton to describe the  
representation it is using for a type.

> I think that learning to
> write code in such a way that some compiler will be able to generate
> good code from it is ultimately not very productive (google for the
> story about Levine the Genius Tailor).

In general, I agree. However, if you only intend to use one compiler  
and discover that compiler is making a bad choice in the critical  
section of your (resource constrained) code, then it pays to hack it.  
That's my scenario. By finding the problem (above), I was able to cut  
my program's memory usage in half. Not too shabby for adding a single  
level of indirection (which is hidden behind a signature anyway).