Erlang and OTP in Action.pdf - Synrc

359
{{profile_ex,'-run/0-fun-1-',0},1},
{{profile_ex,'-run/0-fun-0-',0},1}]}
6> cprof:stop().
5380
7>
I really like this tool because it is so simple and easy to use. At code annotation #1 cprof
is started. No special compilation, you need do nothing in the code being counted to enable
it. This makes it a very useful tool. Many times you will just be interested in the counts of a
specific module instead of the system as a whole. Cprof allows us to do this if we just call
start with the specific name of the module to be profiled.
2> cprof:start(profile_ex).
10
This is advisable for further limiting the impact of the analysis. Either way the next step
we take at code annotation #2 is to pause cprof causing it to stop counting what ever it is
that we were measuring which in this case was the call to profile_ex:run/1. Code annotation
#3 is the call to analysis which dumps the output to the terminal as fairly readable erlang
term. We can see from our term that the results are much as expected. We see the full
1000 calls to both looper and funner. Notice though that the integer_to_list/1 calls don’t
show up. The reason for that is that because cprof uses breakpoints to collect counts only
beam code can be evaluated. BIFs are built right into the emulator, are not beam code, and
therefore can’t be counted. cprof is a simple, easy way to find out what functions are being
called and how many times, nothing more nothing less.
There are other related tools to look at, such as cover for code coverage and the
instrument module for doing memory usage analysis but in general their usage for doing
performance tuning is less common. With these two tools in your arsenal you have a really
nice footing for doing some very powerful performance analysis on your systems. This will
allow you to optimize the way your processes, functions, types and operators are used. This
allows you to measure which performance related refactorings were positive and which were
not. Knowing what works and what does not out of a list of options for implementation is the
best practical tool you have for shaving off microseconds, milliseconds, and depending on the
situation even minutes or hours off execution times so that you can reach your performance
goals.
We now have tools in our arsenal that allow for performance profiling to be done. The
other part of step three
“Profile code and refactor bottlenecks”
©Manning Publications Co. Please post comments or corrections to the Author Online forum:
http://www.manning-sandbox.com/forum.jspaforumID=454