[MLton] Question on profile.fun
Mon, 6 Jun 2005 19:58:47 -0400 (EDT)
> 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
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.