[MLton-devel] experimental release of source-level profiling

[Stephen Weeks]

> [fluet@cfs21 stable.time 5]% mlprof -thresh 1 -raw true wc-scanStream mlmon.out
> 50.03 seconds of CPU time (1.31 seconds GC)
>      function       cur    raw    stack   raw     GC    raw
> ------------------ ----- -------- ----- -------- ---- -------
> doit                0.0%   (0.0s) 97.4% (50.03s) 2.6% (1.31s)
> <GC_arrayAllocate>  0.3%  (0.15s) 97.4% (50.03s) 2.6% (1.31s)

The 97.4% stack for GC_arrayAllocate looks like a bug to me.  I'll
look into it.

> I'm not sure that I like ordering the profiling data with -stack true by
> the time on the stack.  IMHO, it is misleading, because as I read down the
> stack column, I see the times monotonically decreasing, so I naturally
> think that these are all functions on the same stack with the order
> corresponding to the nesting.  But this isn't true.  I don't have a better
> suggestion, but it struck me the first time I looked at it.

I agree it's bad.  I think I'll change it to be ordered by "cur", just
like -profile-stack false.  It's easy enough to look at the dot graph
to understand the stack data.

> When investigating something, I'm tempted to put in a bunch of eta
> expansions for let bindings:
...
> in order to get more information.  It seems that we could provide compiler
> support for that, although I understand that tracing through every let
> binding in the program would be too expensive.

Actually maybe not.  For time profiling, it's just some more labels
that get emitted.  And for allocation profiling, it's some more C
calls, but probably not too many more.

> Perhaps we could support some comment pragmas for enabling and
> disabling profiling of bindings.

I don't see why that's better than explicit thunking.

> I'd also want to make mlprof take an -expand "f" argument to expand the
> let binding of a function named "f".

Makes sense.

> Another place where compiler support might be helpful is with functor
> applications.  I think that it is the case that with a functor F and
> structure X = F ()  structure Y = F (), then we won't be able to
> distinguish between X.f and Y.f from the profiling information.  (Now, it
> may be the case that from stack info, we can make an educated guess.)

Yeah, X.f and Y.f will currently appear as different rows in the table
(nodes in the graph) with the same function name.  It would be nice to
distinguish them more clearly.  I'll look into it.


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel