[MLton] Question on profile.fun

[Matthew Fluet]

> > The discussion and improvements to  -const 'Exn.keepHistory true'  had me 
> > thinking about other improvements to the profiling infra-structure.  I had 
> > the idea of adding the flags:
> > 
> >   -profile-exclude <regexp>  exclude files matching <regexp> from profile
> >   -profile-lib <regexp>  include library files matching <regexp> in profile
> 
> I wonder if these might work well as annotations?

Possibly.  Under this scenario, one would annotate the Basis Library 
implementation with  ann "profileInclude false"  and get the effect of 
-profile-basis true  with  -disable-ann 'profileInclude'.

Note that MLB annotations need to be handled in elaborate, so this sort of
inclusion/exclusion would best work with an implementation that suppressed
EnterLeave insertion in elaborate when processing code excluded from
profiling.  I believe that this is what used to happen with 
-profile-basis {false|true}  but I don't know why things changed to always 
insert profiling EnterLeave statements and let backend/profile.fun keep or 
drop them.

> > But, I have to admit I'm a little confused about the relationship
> > between 
> >   keepSource : SourceInfo.t -> bool	(line 182)
> > and
> >   enter : Push.t list * SourceInfo.t -> Push.t list * bool	(line 316)
> > 
> > In particular, I don't understand what the complicated condition at 
> > line 332 is trying to accomplish. 
> 
> That condition started small and grew over time as I looked at profile
> call graphs and decided what should appear and what shouldn't.  It's
> not based on any hard logic; rather it's based on what I think people
> usually want to see.  So, one way to understand it is to take out
> various clauses and see how the graphs change.
> 
> In summary, the condition decides whether or not a source info (si) 
> is relevant, taking into account the source info (si') of its calling
> context.  So, assuming we've decided we probably want si ("keepSource
> si"),  we will look at the context to see if we will actually use it.

O.k.  This helps some.  

>    So, I guess a third thing that one might like to control is whether
>    certain SML code should count time spent in FFI calls, or the time
>    should be attributed to the underlying C function.

I was going to try to accomplish something like this by making  
-profile-lib runtime  mean that  SourceInfo.isC  satisfying source info 
should be considered relevant.  I agree that C functions should 
furthermore only be kept if their calling context is relevant.