[MLton] Question on profile.fun

[Stephen Weeks]

> Here's what I've worked out thus far:
...
> This seems to approximate the current behavior of profiling. 

It looks good to me.

> Also, I've noted that even with the current implementation, sometime
> basis code is marked in time profiling.

Perhaps the flag name is misleading.  -profile-basis controls whether
the internals of the basis library are profiled.  One still needs to
profile the entry points into the basis library.  Consider a basis
library function (like IntInf.bigMinus) that is called in more than
one place (as IntInf.bigMinus is in tak.sml).  We have no choice but
to allocate ticks to that function, as no other information is
available while the function is running (unless we have -profile-stack
true).  This is why, in the definition of enter, if firstEnter ps =
NONE, we generally want to push the profile info on the local stack.

> Finally, and much to the chagrin of those wanting to map source code onto 
> assembly code, I wonder if we can't simplify time profiling by associating 
> a  currentSourceSeq  field in the gc state and having  profile.fun  
> explicitly change the field as appropriate when time profiling.  

This approach is too intrusive -- it would interfere too much with
running time, and defeat the purpose of time profiling.

> This would appear to simplify the time profiling, as we wouldn't
> need to inspect the PC state, figure out how to grab begin and end
> of text segment, etc.  That ought to make it easier for new
> platforms to support time profiling.

I think we've got it down to as minimal as its going to get.