[MLton] Question on profile.fun

[Stephen Weeks]

> > >   -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'.

Yeah, I can see that this doesn't provide the command-line flexibility
of your proposal.

> 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.

I'm pretty sure it's always been done this way.  I took a look at the
20030111 version of MLton, which is right after -profile-basis was
added, and the elimination was done in profile.fun.  In any case,
annotations don't seem as flexible as the command line, so lets stick
with the flags for now.

I'm still wondering why you need -profile-exclude and -profile-lib.
Why not go for two flags with opposite meanings, like

	-profile-include <regexp>
	-profile-exclude <regexp>

and refer to the special shortened names in the regexp.  So, for
example, the default would be "-profile-exclude '<basis>'".

> >    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.

I was thinking of something with a little more fine grained control,
so that one could specify for different (batches of) files whether or
not C calls should be split out.

  -profile-c <regexp>	separately profile calls to C functions in files
			matching <regexp>.