diff options
author | Björn-Egil Dahlberg <[email protected]> | 2011-10-24 13:57:40 +0200 |
---|---|---|
committer | Björn-Egil Dahlberg <[email protected]> | 2011-10-24 13:57:40 +0200 |
commit | 43c4a54a25e83a33a8383b7a96af20ecd14f10de (patch) | |
tree | ad6d1d5d58550b8a9b58305b7f96a80c4eb3be67 | |
parent | c2e6879aee84f04b2132a52580219b13ce586a13 (diff) | |
download | otp-43c4a54a25e83a33a8383b7a96af20ecd14f10de.tar.gz otp-43c4a54a25e83a33a8383b7a96af20ecd14f10de.tar.bz2 otp-43c4a54a25e83a33a8383b7a96af20ecd14f10de.zip |
otp: Update profiling doc with eprof
-rw-r--r-- | system/doc/efficiency_guide/profiling.xml | 57 |
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> |