1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="manual.css">
<TITLE>
Profiling (ocamlprof)
</TITLE>
</HEAD>
<BODY >
<A HREF="manual030.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="manual032.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>
<H1 CLASS="chapter"><A NAME="htoc199">Chapter 17</A> Profiling (ocamlprof)</H1> <A NAME="c:profiler"></A>
This chapter describes how the execution of Objective Caml
programs can be profiled, by recording how many times functions are
called, branches of conditionals are taken, ...<BR>
<BR>
<H2 CLASS="section"><A NAME="htoc200">17.1</A> Compiling for profiling</H2>
Before profiling an execution, the program must be compiled in
profiling mode, using the <TT>ocamlcp</TT> front-end to the <TT>ocamlc</TT> compiler
(see chapter <A HREF="manual022.html#c:camlc">8</A>). When compiling modules separately,
<TT>ocamlcp</TT> must be used when compiling the modules (production
of <TT>.cmo</TT> files), and can also be used (though this is not strictly
necessary) when linking them together.<BR>
<BR>
<H5 CLASS="paragraph">Note</H5> If a module (<TT>.ml</TT> file) doesn't have a corresponding
interface (<TT>.mli</TT> file), then compiling it with <TT>ocamlcp</TT> will produce
object files (<TT>.cmi</TT> and <TT>.cmo</TT>) that are not compatible with the ones
produced by <TT>ocamlc</TT>, which may lead to problems (if the <TT>.cmi</TT> or
<TT>.cmo</TT> is still around) when switching between profiling and
non-profiling compilations. To avoid this problem, you should always
have a <TT>.mli</TT> file for each <TT>.ml</TT> file.<BR>
<BR>
<H5 CLASS="paragraph">Note</H5> To make sure your programs can be compiled in
profiling mode, avoid using any identifier that begins with
<TT>__ocaml_prof</TT>.<BR>
<BR>
The amount of profiling information can be controlled through the <TT>-p</TT>
option to <TT>ocamlcp</TT>, followed by one or several letters indicating which
parts of the program should be profiled:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<TT><B>a</B></TT><DD CLASS="dd-description"> all options
<DT CLASS="dt-description"><TT><B>f</B></TT><DD CLASS="dd-description"> function calls : a count point is set at the beginning of
function bodies
<DT CLASS="dt-description"><TT><B>i</B></TT><DD CLASS="dd-description"> <B>if ...then ...else ...</B> : count points are set in
both <B>then</B> branch and <B>else</B> branch
<DT CLASS="dt-description"><TT><B>l</B></TT><DD CLASS="dd-description"> <B>while, for</B> loops: a count point is set at the beginning of
the loop body
<DT CLASS="dt-description"><TT><B>m</B></TT><DD CLASS="dd-description"> <B>match</B> branches: a count point is set at the beginning of the
body of each branch
<DT CLASS="dt-description"><TT><B>t</B></TT><DD CLASS="dd-description"> <B>try ...with ...</B> branches: a count point is set at the
beginning of the body of each branch
</DL>
For instance, compiling with <TT>ocamlcp -p film</TT> profiles function calls,
if...then...else..., loops and pattern matching.<BR>
<BR>
Calling <TT>ocamlcp</TT> without the <TT>-p</TT> option defaults to <TT>-p fm</TT>, meaning
that only function calls and pattern matching are profiled.<BR>
<BR>
<B>Note:</B> Due to the implementation of streams and stream patterns as
syntactic sugar, it is hard to predict what parts of stream expressions
and patterns will be profiled by a given flag. To profile a program with
streams, we recommend using <TT>ocamlcp -p a</TT>.<BR>
<BR>
<H2 CLASS="section"><A NAME="htoc201">17.2</A> Profiling an execution</H2>
Running a bytecode executable file that has been compiled with <TT>ocamlcp</TT>
records the execution counts for the specified parts of the program
and saves them in a file called <TT>ocamlprof.dump</TT> in the current directory.<BR>
<BR>
The <TT>ocamlprof.dump</TT> file is written only if the program terminates
normally (by calling <TT>exit</TT> or by falling through). It is not written
if the program terminates with an <TT>uncaught exception</TT>.<BR>
<BR>
If a compatible dump file already exists in the current directory, then the
profiling information is accumulated in this dump file. This allows, for
instance, the profiling of several executions of a program on
different inputs.<BR>
<BR>
<H2 CLASS="section"><A NAME="htoc202">17.3</A> Printing profiling information</H2>
The <TT>ocamlprof</TT> command produces a source listing of the program modules
where execution counts have been inserted as comments. For instance,
<PRE CLASS="verbatim">
ocamlprof foo.ml
</PRE>prints the source code for the <TT>foo</TT> module, with comments indicating
how many times the functions in this module have been called. Naturally,
this information is accurate only if the source file has not been modified
since the profiling execution took place.<BR>
<BR>
The following options are recognized by <TT>ocamlprof</TT>:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>-f</TT> <I>dumpfile</I></B><DD CLASS="dd-description">
Specifies an alternate dump file of profiling information
<DT CLASS="dt-description"><B><TT>-F</TT> <I>string</I></B><DD CLASS="dd-description">
Specifies an additional string to be output with profiling information.
By default, <TT>ocamlprof</TT> will annotate programs with comments of the form
<TT>(* <I>n</I> *)</TT> where <I>n</I> is the counter value for a profiling
point. With option <TT>-F <I>s</I></TT>, the annotation will be
<TT>(* <I>sn</I> *)</TT>.
</DL>
<H2 CLASS="section"><A NAME="htoc203">17.4</A> Time profiling</H2>
Profiling with <TT>ocamlprof</TT> only records execution counts, not the actual
time spent into each function. There is currently no way to perform
time profiling on bytecode programs generated by <TT>ocamlc</TT>.<BR>
<BR>
Native-code programs generated by <TT>ocamlopt</TT> can be profiled for time
and execution counts using the <TT>-p</TT> option and the standard Unix
profiler <TT>gprof</TT>. Just add the <TT>-p</TT> option when compiling and linking
the program:
<PRE>
ocamlopt -o myprog -p <I>other-options files</I>
./myprog
gprof myprog
</PRE>
Caml function names in the output of <TT>gprof</TT> have the following format:
<PRE>
<I>Module-name</I>_<I>function-name</I>_<I>unique-number</I>
</PRE>
Other functions shown are either parts of the Caml run-time system or
external C functions linked with the program.<BR>
<BR>
The output of <TT>gprof</TT> is described in the Unix manual page for
<TT>gprof(1)</TT>. It generally consists of two parts: a “flat” profile
showing the time spent in each function and the number of invocation
of each function, and a “hierarchical” profile based on the call
graph. Currently, only the Intel x86/Linux and Alpha/Digital Unix
ports of <TT>ocamlopt</TT> support the two profiles. On other platforms,
<TT>gprof</TT> will report only the “flat” profile with just time
information. When reading the output of <TT>gprof</TT>, keep in mind that
the accumulated times computed by <TT>gprof</TT> are based on heuristics and
may not be exact.
<BR>
<BR>
<HR>
<A HREF="manual030.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="manual032.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
|
