mlprof output

[Matthew Fluet]

> Look great.  I have one minor question.
> 
> > There is a slight tradeoff here, I think, with the old version of mlprof;
> > because we default to ChunkPerFunc for the native backend, this coarsest
> > grain profiling can correspond to very large chunks of code.  
> 
> I don't see why ChunkPerFunc is relevant.  That doesn't affect the CPS functions 
> at all.

True, but if you are hunting down the most costly portion of a program,
there is different information in knowing that CPS function x_27 took 60%
of the time and knowing that Chunk_8 took 60% of the time.  If I'm willing
to try to wade through the C source, I could potentially narrow in on
which part of x_27 was expensive.  (Similarly, I could use -d 1 with the
new profiler and get approximately the same information.)  I was just
trying to point out that the default information given by the two
profilers is a little different, and we should be aware of that when
looking at the output.