From 84adefa331c4159d432d22840663c38f155cd4c1 Mon Sep 17 00:00:00 2001 From: Erlang/OTP Date: Fri, 20 Nov 2009 14:54:40 +0000 Subject: The R13B03 release. --- lib/tools/doc/src/fprof_chapter.xml | 141 ++++++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 lib/tools/doc/src/fprof_chapter.xml (limited to 'lib/tools/doc/src/fprof_chapter.xml') diff --git a/lib/tools/doc/src/fprof_chapter.xml b/lib/tools/doc/src/fprof_chapter.xml new file mode 100644 index 0000000000..3f40d93f40 --- /dev/null +++ b/lib/tools/doc/src/fprof_chapter.xml @@ -0,0 +1,141 @@ + + + + +
+ + 20012009 + Ericsson AB. All Rights Reserved. + + + The contents of this file are subject to the Erlang Public License, + Version 1.1, (the "License"); you may not use this file except in + compliance with the License. You should have received a copy of the + Erlang Public License along with this software. If not, it can be + retrieved online at http://www.erlang.org/. + + Software distributed under the License is distributed on an "AS IS" + basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See + the License for the specific language governing rights and limitations + under the License. + + + + fprof - The File Trace Profiler + Raimo Niskanen + nobody + + nobody + no + 2001-08-14 + PA1 + fprof_chapter.xml +
+

fprof is a profiling tool that can be used to get a picture of + how much processing time different functions consumes and in which + processes. +

+

fprof uses tracing with timestamps to collect profiling + data. Therfore there is no need for special compilation of any + module to be profiled. +

+

fprof presents wall clock times from the host machine OS, + with the assumption that OS scheduling will randomly load the + profiled functions in a fair way. Both own time i.e the + time used by a function for its own execution, and + accumulated time i.e execution time including called + functions. +

+

Profiling is essentially done in 3 steps:

+ + 1 + Tracing; to file, as mentioned in the previous paragraph. + 2 + Profiling; the trace file is read and raw profile data is + collected into an internal RAM storage on the node. During + this step the trace data may be dumped in text format to file + or console. + 3 + Analysing; the raw profile data is sorted and dumped + in text format either to file or console. + +

Since fprof uses trace to file, the runtime performance + degradation is minimized, but still far from negligible, + especially not for programs that use the filesystem heavily + by themselves. Where you place the trace file is also important, + e.g on Solaris /tmp is usually a good choice, + while any NFS mounted disk is a lousy choice. +

+

Fprof can also skip the file step and trace to a tracer process + of its own that does the profiling in runtime. +

+

The following sections show some examples of how to profile with + Fprof. See also the reference manual + fprof(3). +

+ +
+ Profiling from the source code +

If you can edit and recompile the source code, it is convenient + to insert fprof:trace(start) and + fprof:trace(stop) before and after the code to be + profiled. All spawned processes are also traced. If you want + some other filename than the default try + fprof:trace(start, "my_fprof.trace"). +

+

Then read the trace file and create the raw profile data with + fprof:profile(), or perhaps + fprof:profile(file, "my_fprof.trace") for non-default + filename. +

+

Finally create an informative table dumped on the console with + fprof:analyse(), or on file with + fprof:analyse(dest, []), or perhaps even + fprof:analyse([{dest, "my_fprof.analysis"}, {cols, 120}]) + for a wider listing on non-default filename. +

+

See the fprof(3) manual page + for more options and arguments to the functions + trace, + profile + and + analyse. +

+
+ +
+ Profiling a function +

If you have one function that does the task that you want to + profile, and the function returns when the profiling should + stop, it is convenient to use + fprof:apply(Module, Function, Args) and related for the + tracing step. +

+

If the tracing should continue after the function returns, for + example if it is a start function that spawns processes to be + profiled, you can use + fprof:apply(M, F, Args, [continue | OtherOpts]). + The tracing has to be stopped at a suitable later time using + fprof:trace(stop). +

+
+ +
+ Immediate profiling +

It is also possible to trace immediately into the profiling + process that creates the raw profile data, that is to short + circuit the tracing and profiling steps so that the filesystem + is not used. +

+

Do something like this:

+ 
+{ok, Tracer} = fprof:profile(start),
+fprof:trace([start, {tracer, Tracer}]),
+%% Code to profile
+fprof:trace(stop);
+

This puts less load on the filesystem, but much more on the + Erlang runtime system. +

+
+ + -- cgit v1.2.3