eep

Then copy the resulting file: appname.trace to our machine (before that we
gzip it because of it’s size). On our machine, we transform it into the text
format, suitable for
kcachegrind.

1> eep:convert_tracing("appname").

If you still do not have kcachegrind, go install it:

In Ubuntu:

$ sudo apt-get install kcachegrind

After the conversion has finished, we may begin analyzing the results.

$ kcachegrind callgrind.out.appname

3 important points:

group by “Source File” (or by “ELF Object” if you target is a particular PID);

percentage (“Relative”) is better than absolute time;

percentage relative to its parent (“Relative to Parent”) is even better, otherwise, you can’t understand the damn thing.

“No Grouping” and “Function Cycle” do not give a clear picture of what is
happening. The first option leads to the top lines: gen_server:decode_msg,
gen_server:loop, and only indicates that more time spent in gen_server:* -
thank you, captain! I didn’t understand the results of the second option.

Well, not in reality. Time is often greater than Time1 + Time2 (even if I
measure it, say 100 times). I think it is because timer:tc uses
os:timestamp and Time includes some switching (when scheduler runs other
process).