[MLton-user] Tracking down allocations

[Joe Hurd]

Update: I was able to eliminate the allocations by manually un-nesting
the inner function in the obvious way:

fun g intArrayRef1 intArrayRef2 i j k = ...big but non-recursive...

fun f intArrayRef1 intArrayRef2 i =
 let
   val j = ...
   val k = ...
 in
   g intArrayRef1 intArrayRef2 i j k
 end;

However, I'm not going to leave the code like this, because it looks
like a mess. So I wonder why MLton's internal un-nesting doesn't have
the same effect?

Joe

On 7/15/07, Joe Hurd <joe at gilith.com> wrote:
> Hi Ville,
>
> Thanks for the inlining suggestion: it reduced the allocations by 25%
> and also gave the program an overall speed-up of 20%. However, there
> are still 30,000,000,000 allocations at the program point in my first
> email that I can't explain.
>
> 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.
>
> Does MLton "allocations" refer to stack manipulations as well as
> allocating cells on the heap, or am I missing something?
>
> Joe
>
> On 7/15/07, Ville Laurikari <ville at laurikari.net> wrote:
> > On Sun, Jul 15, 2007 at 01:44:32AM +0100, Joe Hurd wrote:
> > > mlprof -show-line true -raw true x mlmon.out
> > >
> > > pointed me to the "let" line with 40,000,000,000 allocations being
> > > done. Where exactly should I look next to see where the allocations
> > > are being done?
> >
> > I did a similar excercise a few weeks ago.  I was able to eliminate
> > all allocations in my program by compiling with "mlton -inline 100000"
> > instead of the default.  Maybe that could help in your case as well?
> >
> > In my program, the allocations that weren't eliminated with default
> > inlining were just argument tuples for a couple of functions.  The
> > functions were extremely short and I would have thought they would
> > have been inlined and the tuples eliminated, but that was not the
> > case.
> >
> > --
> > http://www.iki.fi/vl/
> >
>