<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta name="robots" content="index,nofollow">



<title>HowProfilingWorks - MLton Standard ML Compiler (SML Compiler)</title>
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="all" href="common.css">
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="screen" href="screen.css">
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="print" href="print.css">


<link rel="Start" href="Home">


</head>

<body lang="en" dir="ltr">

<table bgcolor = lightblue cellspacing = 0 style = "border: 0px;" width = 100%>
  <tr>
    <td style = "
		border: 0px;
		color: darkblue; 
		font-size: 150%;
		text-align: left;">
      <a class = mltona href="Home">MLton 20051202</a>
    <td style = "
		border: 0px;
		font-size: 150%;
		text-align: center;
		width: 50%;">
      HowProfilingWorks
    <td style = "
		border: 0px;
		text-align: right;">
      <table cellspacing = 0 style = "border: 0px">
        <tr style = "vertical-align: middle;">
      </table>
  <tr style = "background-color: white;">
    <td colspan = 3
	style = "
		border: 0px;
		font-size:70%;
		text-align: right;">
      <a href = "Home">Home</a>
      &nbsp;<a href = "Index">Index</a>
      &nbsp;
</table>
<div id="content" lang="en" dir="ltr">
Here's how <a href="Profiling">Profiling</a> works.  If profiling is on, the front end (elaborator) inserts <tt>Enter</tt> and <tt>Leave</tt> statements into the source program for function entry and exit.   For example, 
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> f n = <B><FONT COLOR="#A020F0">if</FONT></B> n = <B><FONT COLOR="#5F9EA0">0</FONT></B> <B><FONT COLOR="#A020F0">then</FONT></B> <B><FONT COLOR="#5F9EA0">0</FONT></B> <B><FONT COLOR="#A020F0">else</FONT></B> <B><FONT COLOR="#5F9EA0">1</FONT></B> + f (n - <B><FONT COLOR="#5F9EA0">1</FONT></B>)
</PRE>
<p>
 becomes 
<pre class=code>
<B><FONT COLOR="#A020F0">fun</FONT></B> f n = 
   <B><FONT COLOR="#A020F0">let</FONT></B>
      <B><FONT COLOR="#A020F0">val</FONT></B> () = Enter <FONT COLOR="#BC8F8F"><B>&quot;f&quot;</FONT></B>
      <B><FONT COLOR="#A020F0">val</FONT></B> res = (<B><FONT COLOR="#A020F0">if</FONT></B> n = <B><FONT COLOR="#5F9EA0">0</FONT></B> <B><FONT COLOR="#A020F0">then</FONT></B> <B><FONT COLOR="#5F9EA0">0</FONT></B> <B><FONT COLOR="#A020F0">else</FONT></B> <B><FONT COLOR="#5F9EA0">1</FONT></B> + f (n - <B><FONT COLOR="#5F9EA0">1</FONT></B>))
                <B><FONT COLOR="#A020F0">handle</FONT></B> e =&gt; (Leave <FONT COLOR="#BC8F8F"><B>&quot;f&quot;</FONT></B>; <B><FONT COLOR="#A020F0">raise</FONT></B> e)
      <B><FONT COLOR="#A020F0">val</FONT></B> () = Leave <FONT COLOR="#BC8F8F"><B>&quot;f&quot;</FONT></B>
   <B><FONT COLOR="#A020F0">in</FONT></B> 
      res
   <B><FONT COLOR="#A020F0">end</FONT></B>
</PRE>
 Actually there is a bit more information than just the source function name; there is also lexical nesting and file position.  
</p>
<p>
Most of the middle of the compiler ignores, but preserves, <tt>Enter</tt> and <tt>Leave</tt>.  However, so that profiling preserves tail calls, the <a href="Shrink">Ssa shrinker</a> has an optimization that notices when the only operations that cause a call to be a nontail call are profiling operations, and if so, moves them before the call, turning it into a tail call. If you observe a program that has a tail call that appears to be turned into a nontail when compiled with profiling, please <a href="Bug">report a bug</a>. 
</p>
<p>
There is the <tt>checkProf</tt> function in 
<a href = "http://mlton.org/cgi-bin/viewsvn.cgi/mlton/tags/on-20051202-release/mlton/ssa/type-check.fun?view=markup"><img src="moin-www.png" alt="[WWW]" height="11" width="11">type-check.fun</a>
, which checks that the <tt>Enter</tt>/<tt>Leave</tt> statements match up. 
</p>
<p>
In the backend, just before translating to the <a href="Machine">Machine</a> IL, the profiler uses the <tt>Enter</tt>/<tt>Leave</tt> statements to infer the "local" portion of the control stack at each program point.  The profiler then removes the <tt>Enter</tt>s/<tt>Leave</tt>s and inserts different information depending on which kind of profiling is happening.  For time profiling, the profiler inserts labels that cover the code (i.e. each statement has a unique label in its basic block that prefixes it) and associates each label with the local control stack.  For allocation profiling, the profiler inserts calls to a C function that will maintain byte counts.  With stack profiling, the profiler also inserts a call to a C function at each nontail call in order to maintain information at runtime about what SML functions are on the stack. 
</p>
<p>
At run time, the profiler associates counters (either clock ticks or byte counts) with source functions.  When the program finishes, the profiler writes the counts out to the <tt>mlmon.out</tt> file.  Then, <tt>mlprof</tt> uses source information stored in the executable to associate the counts in the <tt>mlmon.out</tt> file with source functions. 
</p>
<p>
For time profiling, the profiler catches the <tt>SIGPROF</tt> signal 100 times per second and increments the appropriate counter, determined by looking at the label prefixing the current program counter and mapping that to the current source function. 
</p>
<h2 id="head-bcaa33a7ae44bd5042c37a9cdbea7f843b1cf7c8">Caveats</h2>
<p>
There may be a few missed clock ticks or bytes allocated at the very end of the program after the data is written. 
</p>
<p>
Profiling has not been tested with signals or threads.  In particular, stack profiling may behave strangely. 
</p>
</div>



<p>
<hr>
Last edited on 2005-12-01 04:35:20 by <span title="ppp-71-139-183-221.dsl.snfc21.pacbell.net"><a href="StephenWeeks">StephenWeeks</a></span>.
</body></html>
