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

Matthew Fluet fluet@CS.Cornell.EDU
Fri, 17 Jan 2003 08:40:53 -0500 (EST)


> Please try out the profiler and let me know of problems, or ideas
> about how to better visualize the data.

[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)
<main>              0.0%   (0.0s) 97.4% (50.03s) 2.6% (1.31s)
loop                0.0%  (0.01s) 97.0% (49.80s) 2.1% (1.10s)
wc                  0.0%   (0.0s) 97.0% (49.79s) 2.1% (1.10s)
scanStream         32.6% (16.75s) 96.8% (49.69s) 2.1% (1.08s)
loop               27.9% (14.31s) 64.2% (32.94s) 2.1% (1.08s)
input1              5.4%  (2.79s) 36.2% (18.61s) 2.1% (1.08s)
sub                19.0%  (9.78s) 19.0%  (9.78s) 0.0%  (0.0s)
sub                 0.0%   (0.0s) 19.0%  (9.78s) 0.0%  (0.0s)
next                0.0%  (0.01s) 11.8%  (6.04s) 2.1% (1.08s)
<Posix_IO_read>    11.4%  (5.84s) 11.4%  (5.84s) 0.0%  (0.0s)
readArr             0.0%   (0.0s) 11.4%  (5.84s) 0.0%  (0.0s)

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.

Otherwise, though, I am really impressed with the profiling support and I
think it will prove quite useful.

When investigating something, I'm tempted to put in a bunch of eta
expansions for let bindings:

fun f n = let val x = (fn () => ...) ()
              val y = (fn () => ...) ()
          in x + 1
          end

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.  Perhaps we could support
some comment pragmas for enabling and disabling profiling of bindings.
I'd also want to make mlprof take an -expand "f" argument to expand the
let binding of a function named "f".

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

>From a developer's point of view, here are a few things that might be nice
down the line:
 - tools for manipulating .SSA and .DOT files
   1. extract/color code corresponding to a source function



-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel