[MLton] Question on profile.fun

[Matthew Fluet]

> You could determine this by separating out the call to shrink from
> flatten into a separate pass and then dropping profile labels in
> between flattening and shrinking.

Yes, I'll check that out.

> > Flatten.flatten doesn't appear to be sensitive to the presence of
> > profiling statements in the program.  But, there is something
> > definitely going on there.
> 
> Maybe.  At least the shrinker does refer to profile annotations.  But
> the problem could be due to profile annotations messing up an earlier
> pass, which then messes up the input to flatten. 

I don't think you can blame any earlier pass.  There isn't the slowdown
when I drop profiling annotations immediately before Flatten.flatten.  And 
there is the slowdown when I drop profiling annotations immediately after 
Flatten.flatten.  If the input to flatten were already messed up, then 
dropping the profiling annotations immediately before flatten would show 
the slowdown.

On the other hand, the opposite might be true.  Namely, that the really 
important optimization that is being missed isn't in flatten, but rather 
in some pass after flatten.  Having the profiling annotations through to 
flatten is enough to throw the program out of line so some latter 
optimizations are missed.

> The easiest thing to
> do might be to find out the hot loop in wc-scanstream, and then see if
> it's the same coming in to flatten, and if so then see what happens to
> it in the two different ways flatten can be run (i.e. with or without
> profiling labels dropped before it).

Another good idea to check out.