← Back to branch summary

~ubuntu-branches/ubuntu/trusty/erlang/trusty

« back to all changes in this revision

Viewing changes to system/doc/efficiency_guide/profiling.xml

  • Committer: Bazaar Package Importer
  • Author(s): Clint Byrum
  • Date: 2011-05-05 15:48:43 UTC
  • mfrom: (3.5.13 sid)
  • Revision ID: james.westby@ubuntu.com-20110505154843-0om6ekzg6m7ugj27
Tags: 1:14.b.2-dfsg-3ubuntu1
* Merge from debian unstable.  Remaining changes:
  - Drop libwxgtk2.8-dev build dependency. Wx isn't in main, and not
    supposed to.
  - Drop erlang-wx binary.
  - Drop erlang-wx dependency from -megaco, -common-test, and -reltool, they
    do not really need wx. Also drop it from -debugger; the GUI needs wx,
    but it apparently has CLI bits as well, and is also needed by -megaco,
    so let's keep the package for now.
  - debian/patches/series: Do what I meant, and enable build-options.patch
    instead.
* Additional changes:
  - Drop erlang-wx from -et
* Dropped Changes:
  - patches/pcre-crash.patch: CVE-2008-2371: outer level option with
    alternatives caused crash. (Applied Upstream)
  - fix for ssl certificate verification in newSSL: 
    ssl_cacertfile_fix.patch (Applied Upstream)
  - debian/patches/series: Enable native.patch again, to get stripped beam
    files and reduce the package size again. (build-options is what
    actually accomplished this)
  - Remove build-options.patch on advice from upstream and because it caused
    odd build failures.

Show diffs side-by-side

added added

removed removed

Lines of Context:
system/doc/efficiency_guide/profiling.xml
 
1
<?xml version="1.0" encoding="latin1" ?>
 
2
<!DOCTYPE chapter SYSTEM "chapter.dtd">
 
3
 
 
4
<chapter>
 
5
  <header>
 
6
    <copyright>
 
7
      <year>2001</year><year>2009</year>
 
8
      <holder>Ericsson AB. All Rights Reserved.</holder>
 
9
    </copyright>
 
10
    <legalnotice>
 
11
      The contents of this file are subject to the Erlang Public License,
 
12
      Version 1.1, (the "License"); you may not use this file except in
 
13
      compliance with the License. You should have received a copy of the
 
14
      Erlang Public License along with this software. If not, it can be
 
15
      retrieved online at http://www.erlang.org/.
 
16
    
 
17
      Software distributed under the License is distributed on an "AS IS"
 
18
      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
 
19
      the License for the specific language governing rights and limitations
 
20
      under the License.
 
21
    
 
22
    </legalnotice>
 
23
 
 
24
    <title>Profiling</title>
 
25
    <prepared>Ingela Anderton</prepared>
 
26
    <docno></docno>
 
27
    <date>2001-11-02</date>
 
28
    <rev></rev>
 
29
    <file>profiling.xml</file>
 
30
  </header>
 
31
 
 
32
  <section>
 
33
    <title>Do not guess about performance - profile</title>
 
34
 
 
35
    <p>Even experienced software developers often guess wrong about where
 
36
    the performance bottlenecks are in their programs.</p>
 
37
 
 
38
    <p>Therefore, profile your program to see where the performance
 
39
    bottlenecks are and concentrate on optimizing them.</p>
 
40
 
 
41
    <p>Erlang/OTP contains several tools to help finding bottlenecks.</p>
 
42
 
 
43
    <p><c>fprof</c> and <c>eprof</c> provide the most detailed information
 
44
    about where the time is spent, but they significantly slow downs the
 
45
    programs they profile.</p>
 
46
 
 
47
    <p>If the program is too big to be profiled by <c>fprof</c> or <c>eprof</c>,
 
48
    <c>cover</c> and <c>cprof</c> could be used to locate parts of the
 
49
    code that should be more thoroughly profiled using <c>fprof</c> or
 
50
    <c>eprof</c>.</p>
 
51
 
 
52
    <p><c>cover</c> provides execution counts per line per process,
 
53
    with less overhead than <c>fprof/eprof</c>. Execution counts can
 
54
    with some caution be used to locate potential performance bottlenecks.
 
55
    The most lightweight tool is <c>cprof</c>, but it only provides execution
 
56
    counts on a function basis (for all processes, not per process).</p>
 
57
  </section>
 
58
 
 
59
  <section>
 
60
    <title>Big systems</title>
 
61
    <p>If you have a big system it might be interesting to run profiling
 
62
      on a simulated and limited scenario to start with. But bottlenecks
 
63
      have a tendency to only appear or cause problems when
 
64
      there are many things going on at the same time, and when there
 
65
      are many nodes involved. Therefore it is desirable to also run
 
66
      profiling in a system test plant on a real target system.</p>
 
67
    <p>When your system is big you do not want to run the profiling
 
68
      tools on the whole system. You want to concentrate on processes
 
69
      and modules that you know are central and stand for a big part of the
 
70
      execution.</p>
 
71
  </section>
 
72
 
 
73
  <section>
 
74
    <title>What to look for</title>
 
75
    <p>When analyzing the result file from the profiling activity
 
76
      you should look for functions that are called many
 
77
      times and have a long "own" execution time (time excluded calls
 
78
      to other functions). Functions that just are called very
 
79
      many times can also be interesting, as even small things can add
 
80
      up to quite a bit if they are repeated often. Then you need to
 
81
      ask yourself what can I do to reduce this time. Appropriate
 
82
      types of questions to ask yourself are: </p>
 
83
    <list type="bulleted">
 
84
      <item>Can I reduce the number of times the function is called?</item>
 
85
      <item>Are there tests that can be run less often if I change
 
86
       the order of tests?</item>
 
87
      <item>Are there redundant tests that can be removed? </item>
 
88
      <item>Is there some expression calculated giving the same result
 
89
       each time? </item>
 
90
      <item>Is there other ways of doing this that are equivalent and
 
91
       more efficient?</item>
 
92
      <item>Can I use another internal data representation to make
 
93
       things more efficient? </item>
 
94
    </list>
 
95
    <p>These questions are not always trivial to answer. You might
 
96
      need to do some benchmarks to back up your theory, to avoid
 
97
      making things slower if your theory is wrong. See <seealso marker="#benchmark">benchmarking</seealso>.</p>
 
98
  </section>
 
99
 
 
100
  <section>
 
101
    <title>Tools</title>
 
102
 
 
103
    <section>
 
104
      <title>fprof</title>
 
105
      <p><c>fprof</c> measures the execution time for each function,
 
106
        both own time i.e how much time a function has used for its
 
107
        own execution, and accumulated time i.e. including called
 
108
        functions. The values are displayed per process. You also get
 
109
        to know how many times each function has been
 
110
        called. <c>fprof</c> is based on trace to file in order to
 
111
        minimize runtime performance impact. Using fprof is just a
 
112
        matter of calling a few library functions, see fprof manual
 
113
        page under the application tools.</p>
 
114
      <p><c>fprof</c> was introduced in version R8 of Erlang/OTP. Its
 
115
        predecessor <c>eprof</c> that is based on the Erlang trace BIFs,
 
116
        is still available, see eprof manual page under the
 
117
        application tools. Eprof shows how much time has been used by
 
118
        each process, and in which function calls this time has been
 
119
        spent.  Time is shown as percentage of total time, not as
 
120
        absolute time.</p>
 
121
    </section>
 
122
 
 
123
    <section>
 
124
      <title>cover</title>
 
125
      <p><c>cover</c>'s primary use is coverage analysis to verify
 
126
        test cases, making sure all relevant code is covered.
 
127
        <c>cover</c> counts how many times each executable line of
 
128
        code is executed when a program is run. This is done on a per
 
129
        module basis. Of course this information can be used to
 
130
        determine what code is run very frequently and could therefore
 
131
        be subject for optimization. Using cover is just a matter of
 
132
        calling a few library functions, see cover manual
 
133
        page under the application tools.</p>
 
134
    </section>
 
135
 
 
136
    <section>
 
137
      <title>cprof</title>
 
138
      <p><c>cprof</c> is something in between <c>fprof</c> and
 
139
        <c>cover</c> regarding features. It counts how many times each
 
140
        function is called when the program is run, on a per module
 
141
        basis. <c>cprof</c> has a low performance degradation (versus
 
142
        <c>fprof</c> and <c>eprof</c>) and does not need to recompile
 
143
        any modules to profile (versus <c>cover</c>).</p>
 
144
    </section>
 
145
 
 
146
    <section>
 
147
      <title>Tool summarization</title>
 
148
      <table>
 
149
        <row>
 
150
          <cell align="center" valign="middle">Tool</cell>
 
151
          <cell align="center" valign="middle">Results</cell>
 
152
          <cell align="center" valign="middle">Size of result</cell>
 
153
          <cell align="center" valign="middle">Effects on program execution time</cell>
 
154
          <cell align="center" valign="middle">Records number of calls</cell>
 
155
          <cell align="center" valign="middle">Records Execution time</cell>
 
156
          <cell align="center" valign="middle">Records called by</cell>
 
157
          <cell align="center" valign="middle">Records garbage collection</cell>
 
158
        </row>
 
159
        <row>
 
160
          <cell align="left" valign="middle"><c>fprof </c></cell>
 
161
          <cell align="left" valign="middle">per process to screen/file </cell>
 
162
          <cell align="left" valign="middle">large </cell>
 
163
          <cell align="left" valign="middle">significant slowdown </cell>
 
164
          <cell align="left" valign="middle">yes  </cell>
 
165
          <cell align="left" valign="middle">total and own</cell>
 
166
          <cell align="left" valign="middle">yes </cell>
 
167
          <cell align="left" valign="middle">yes </cell>
 
168
        </row>
 
169
        <row>
 
170
          <cell align="left" valign="middle"><c>eprof </c></cell>
 
171
          <cell align="left" valign="middle">per process/function to screen/file </cell>
 
172
          <cell align="left" valign="middle">medium </cell>
 
173
          <cell align="left" valign="middle">significant slowdown </cell>
 
174
          <cell align="left" valign="middle">yes </cell>
 
175
          <cell align="left" valign="middle">only total </cell>
 
176
          <cell align="left" valign="middle">no </cell>
 
177
          <cell align="left" valign="middle">no </cell>
 
178
        </row>
 
179
        <row>
 
180
          <cell align="left" valign="middle"><c>cover </c></cell>
 
181
          <cell align="left" valign="middle">per module to screen/file</cell>
 
182
          <cell align="left" valign="middle">small </cell>
 
183
          <cell align="left" valign="middle">moderate slowdown</cell>
 
184
          <cell align="left" valign="middle">yes, per line  </cell>
 
185
          <cell align="left" valign="middle">no </cell>
 
186
          <cell align="left" valign="middle">no </cell>
 
187
          <cell align="left" valign="middle">no </cell>
 
188
        </row>
 
189
        <row>
 
190
          <cell align="left" valign="middle"><c>cprof </c></cell>
 
191
          <cell align="left" valign="middle">per module to caller</cell>
 
192
          <cell align="left" valign="middle">small </cell>
 
193
          <cell align="left" valign="middle">small slowdown </cell>
 
194
          <cell align="left" valign="middle">yes </cell>
 
195
          <cell align="left" valign="middle">no </cell>
 
196
          <cell align="left" valign="middle">no </cell>
 
197
          <cell align="left" valign="middle">no </cell>
 
198
        </row>
 
199
        <tcaption></tcaption>
 
200
      </table>
 
201
    </section>
 
202
  </section>
 
203
 
 
204
  <section>
 
205
    <marker id="benchmark"></marker>
 
206
    <title>Benchmarking</title>
 
207
 
 
208
    <p>The main purpose of benchmarking is to find out which
 
209
    implementation of a given algorithm or function is the fastest.
 
210
    Benchmarking is far from an exact science. Today's operating systems
 
211
    generally run background tasks that are difficult to turn off.
 
212
    Caches and multiple CPU cores doesn't make it any easier.
 
213
    It would be best to run Unix-computers in single-user mode when
 
214
    benchmarking, but that is inconvenient to say the least for casual
 
215
    testing.</p>
 
216
    
 
217
    <p>Benchmarks can measure wall-clock time or CPU time.</p>
 
218
 
 
219
    <p><seealso marker="stdlib:timer#tc/3">timer:tc/3</seealso> measures
 
220
    wall-clock time. The advantage with wall-clock time is that I/O,
 
221
    swapping, and other activities in the operating-system kernel are
 
222
    included in the measurements. The disadvantage is that the
 
223
    the measurements will vary wildly. Usually it is best to run the
 
224
    benchmark several times and note the shortest time - that time should
 
225
    be the minimum time that is possible to achieve under the best of
 
226
    circumstances.</p>
 
227
 
 
228
    <p><seealso marker="erts:erlang#statistics/1">statistics/1</seealso>
 
229
    with the argument <c>runtime</c> measures CPU time spent in the Erlang
 
230
    virtual machine. The advantage is that the results are more
 
231
    consistent from run to run. The disadvantage is that the time
 
232
    spent in the operating system kernel (such as swapping and I/O)
 
233
    are not included. Therefore, measuring CPU time is misleading if
 
234
    any I/O (file or sockets) are involved.</p>
 
235
 
 
236
    <p>It is probably a good idea to do both wall-clock measurements and
 
237
    CPU time measurements.</p>
 
238
 
 
239
    <p>Some additional advice:</p>
 
240
 
 
241
    <list type="bulleted">
 
242
    <item>The granularity of both types measurement could be quite
 
243
    high so you should make sure that each individual measurement
 
244
    lasts for at least several seconds.</item>
 
245
 
 
246
    <item>To make the test fair, each new test run should run in its own,
 
247
    newly created Erlang process. Otherwise, if all tests runs in the
 
248
    same process, the later tests would start out with larger heap sizes
 
249
    and therefore probably does less garbage collections. You could
 
250
    also consider restarting the Erlang emulator between each test.</item>
 
251
 
 
252
    <item>Do not assume that the fastest implementation of a given algorithm
 
253
    on computer architecture X also is the fast on computer architecture Y.</item>
 
254
 
 
255
    </list>
 
256
  </section>
 
257
</chapter>
 
258