MLton has a rudimentary profiling facility called mlprof
,
which is similar in usage to gprof
. Here is an example run
from within the examples/
directory showing how to generate
profiling information.
% mlton -p profiling.sml
% profiling
% ../bin/mlprof profiling.c profiling gmon.out
145 ticks total
tak_0 34.48%
mpz_mul (C) 15.17%
__mpn_mul (C) 13.10%
MLTON_do_mul (C) 8.28%
Loop (C @ 0x804de90) 6.21%
answer (C @ 0x8049b20) 6.21%
__mpn_mul_1 (C) 5.52%
**C overhead** 4.83%
MLTON_smallMul (C) 4.83%
currentTime (C @ 0x804b358) 0.69%
roundPage (C) 0.69%
In summary, generating profiling information takes three steps.
-p
switch.
gmon.out
.
mlprof
on the .c
file, the executable, and the
gmon.out
file.
Unfortunately, the profiling information may be hard to interpret,
because it does not refer to the source program --
mlprof
reports the percentage of time spent in three
different kinds of code: cps functions, C functions, and
C overhead.
These are as close to the source as you're gonna get. They refer to
toplevel functions in MLton's cps intermediate language after much
optimization has been performed on the source. When you
compile -p
, MLton automatically saves a .cps
file containing the cps program that the profiling data refers to.
MLton takes some care to preserve source names, but due to anonymous
functions, inlining, monomorphisation, closure conversion, and other
optimizations, there is often quite a difference between the source
and the optimized cps program. The source names are always mangled by
adding a suffix of _n
for some n (e.g. tak_0
).
Names in the source may disappear (e.g. f
is nowhere to be
found because it has been turned into a loop within main) or new names
may appear from the SML basis library code that is prefixed to your
program.
There are many examples of this in the table above. These include
functions which implement the garbage collector
(e.g. foreachGlobal
, finishGC
),
IntInf (e.g. mpz_mul
, MLTON_smallMul
), or other
runtime system functions.
C functions are labeled with a (C)
, and C static
functions are labeled with (C @ address)
This refers to code that MLton inserts because of its strategy for
compiling to C. All of this overhead is grouped together under the
heading **C overhead**
. C overhead includes trampolining,
switches within C procedures, and GC initialization.
mlprof
is written in
Python, which must be installed on your system.
mlprof
depends on the actual format of the gmon.out file and
on the objdump utility, so it might not work on all distributions of
Linux. In particular, it requires glibc
and it definitely
works with objdump
version 2.9.1 (which is what you get on
Red Hat 5.2 and 6.0). If you need the profiler for another
configuration, please send mail to
MLton@research.nj.nec.com with your request, along with a
sample gmon.out
file and the objdump
version number.