aboutsummaryrefslogtreecommitdiffstats
path: root/system/doc/efficiency_guide
diff options
context:
space:
mode:
authorBjörn-Egil Dahlberg <[email protected]>2011-10-24 13:57:40 +0200
committerBjörn-Egil Dahlberg <[email protected]>2011-10-24 13:57:40 +0200
commit43c4a54a25e83a33a8383b7a96af20ecd14f10de (patch)
treead6d1d5d58550b8a9b58305b7f96a80c4eb3be67 /system/doc/efficiency_guide
parentc2e6879aee84f04b2132a52580219b13ce586a13 (diff)
downloadotp-43c4a54a25e83a33a8383b7a96af20ecd14f10de.tar.gz
otp-43c4a54a25e83a33a8383b7a96af20ecd14f10de.tar.bz2
otp-43c4a54a25e83a33a8383b7a96af20ecd14f10de.zip
otp: Update profiling doc with eprof
Diffstat (limited to 'system/doc/efficiency_guide')
-rw-r--r--system/doc/efficiency_guide/profiling.xml57
1 files changed, 37 insertions, 20 deletions
diff --git a/system/doc/efficiency_guide/profiling.xml b/system/doc/efficiency_guide/profiling.xml
index 13165a0ede..65ba4b3369 100644
--- a/system/doc/efficiency_guide/profiling.xml
+++ b/system/doc/efficiency_guide/profiling.xml
@@ -40,9 +40,13 @@
<p>Erlang/OTP contains several tools to help finding bottlenecks.</p>
- <p><c>fprof</c> and <c>eprof</c> provide the most detailed information
- about where the time is spent, but they significantly slow downs the
- programs they profile.</p>
+ <p><c>fprof</c> provide the most detailed information
+ about where the time is spent, but it significantly slows down the
+ program it profiles.</p>
+
+ <p><c>eprof</c> provides time information of each function used
+ in the program. No callgraph is produced but <c>eprof</c> has
+ considerable less impact on the program profiled.</p>
<p>If the program is too big to be profiled by <c>fprof</c> or <c>eprof</c>,
<c>cover</c> and <c>cprof</c> could be used to locate parts of the
@@ -50,7 +54,7 @@
<c>eprof</c>.</p>
<p><c>cover</c> provides execution counts per line per process,
- with less overhead than <c>fprof/eprof</c>. Execution counts can
+ with less overhead than <c>fprof</c>. Execution counts can
with some caution be used to locate potential performance bottlenecks.
The most lightweight tool is <c>cprof</c>, but it only provides execution
counts on a function basis (for all processes, not per process).</p>
@@ -102,35 +106,45 @@
<section>
<title>fprof</title>
- <p><c>fprof</c> measures the execution time for each function,
+ <p>
+ <c>fprof</c> measures the execution time for each function,
both own time i.e how much time a function has used for its
own execution, and accumulated time i.e. including called
functions. The values are displayed per process. You also get
to know how many times each function has been
called. <c>fprof</c> is based on trace to file in order to
minimize runtime performance impact. Using fprof is just a
- matter of calling a few library functions, see fprof manual
- page under the application tools.</p>
- <p><c>fprof</c> was introduced in version R8 of Erlang/OTP. Its
- predecessor <c>eprof</c> that is based on the Erlang trace BIFs,
- is still available, see eprof manual page under the
- application tools. Eprof shows how much time has been used by
- each process, and in which function calls this time has been
- spent. Time is shown as percentage of total time, not as
- absolute time.</p>
+ matter of calling a few library functions, see
+ <seealso marker="tools:fprof">fprof</seealso>
+ manual page under the application tools.<c>fprof</c> was introduced in
+ version R8 of Erlang/OTP.
+ </p>
</section>
+ <section>
+ <title>eprof</title>
+ <p>
+ <c>eprof</c> is based on the Erlang trace_info BIFs. Eprof shows how much time has been used by
+ each process, and in which function calls this time has been
+ spent. Time is shown as percentage of total time and absolute time.
+ See <seealso marker="tools:eprof">eprof</seealso> for
+ additional information.
+ </p>
+ </section>
+
<section>
<title>cover</title>
- <p><c>cover</c>'s primary use is coverage analysis to verify
+ <p>
+ <c>cover</c>'s primary use is coverage analysis to verify
test cases, making sure all relevant code is covered.
<c>cover</c> counts how many times each executable line of
code is executed when a program is run. This is done on a per
module basis. Of course this information can be used to
determine what code is run very frequently and could therefore
be subject for optimization. Using cover is just a matter of
- calling a few library functions, see cover manual
- page under the application tools.</p>
+ calling a few library functions, see
+ <seealso marker="tools:cover">cover</seealso>
+ manual page under the application tools.</p>
</section>
<section>
@@ -139,8 +153,11 @@
<c>cover</c> regarding features. It counts how many times each
function is called when the program is run, on a per module
basis. <c>cprof</c> has a low performance degradation effect (versus
- <c>fprof</c> and <c>eprof</c>) and does not need to recompile
- any modules to profile (versus <c>cover</c>).</p>
+ <c>fprof</c>) and does not need to recompile
+ any modules to profile (versus <c>cover</c>).
+ See <seealso marker="tools:cprof">cprof</seealso> manual page for additional
+ information.
+ </p>
</section>
<section>
@@ -170,7 +187,7 @@
<cell align="left" valign="middle"><c>eprof </c></cell>
<cell align="left" valign="middle">per process/function to screen/file </cell>
<cell align="left" valign="middle">medium </cell>
- <cell align="left" valign="middle">significant slowdown </cell>
+ <cell align="left" valign="middle">small slowdown </cell>
<cell align="left" valign="middle">yes </cell>
<cell align="left" valign="middle">only total </cell>
<cell align="left" valign="middle">no </cell>