[MLton-user] Tracking down allocations

[Matthew Fluet]

> I'm a little puzzled by why allocations are done at all when calling
> functions. All my functions are first order (though as I showed some
> are nested), so I assumed that calling them would simply be a case of
> putting the arguments on the stack. Most of them are curried,
> including the one that is causing all the allocations. I was also
> careful to ensure that the return type of all the critical functions
> was either unit or a simple type such as bool or int.

That does sound as though there shouldn't be any extraneous allocation 
going on.  As Ville observed, MLton doesn't guarantee to flatten all tuple 
arguments (though, it is an interesting property of SML that a compiler 
could eliminate all tuples (at the expense of breaking sharing of data)), 
so there can be some allocation due to such programs.

Also, un-curried functions are generally better than curried functions, 
since in
   (fn x => fn y => fn z => ...) a b c
this technically corresponds to allocating and applying two partially 
applied functions.  MLton used to have an uncurry optimization in an early 
(higher-order) IL, though it has been disabled for many years; the later 
optimizations usually succeed in eliminating the intermediate closures.

Finally, profiling does not (by default) account for activites going on in 
the implementation of the Basis Library; rather, such time and 
allocation counts are allocated to the user code that invokes the Basis 
Library functions.  So, if your allocating function is calling Basis 
Library functions, you may be seeing allocation from the Basis Library 
implementation.  You can differentiate user code from Basis Library code 
by compiling with:
   -profile-include '<basis>'
(for MLton 20051202) or
   -profile-include '\$\(SML_LIB\)'
(for a recent trunk build).

> Does MLton "allocations" refer to stack manipulations as well as
> allocating cells on the heap, or am I missing something?

No, the allocation profiling does not account for stack manipulations.