cprof can be useful when you want to discover the bottlenecks related
to function calls.

Before running the code, it invokes the app.start task which compiles
and loads your project. Then the target expression is profiled, together
with all matching function calls, by setting breakpoints containing
counters. These can only be set on BEAM code so BIFs cannot be call
count traced.

The default output contains data gathered from all matching functions. The left
column structures each module and its total call count trace is presented on the right.
Each module has its count discriminated by function below. The <-- symbol is meant to
help visualize where a new module call count begins.

The first row (Total) is the sum of all function calls. In the last row the number of
matching functions that were considered for profiling is presented.

When --matching option is specified, call count tracing will be started only for
the functions matching the given pattern:

The pattern can be a module name, such as String to count all calls to that module,
a call without arity, such as String.split, to count all calls to that function
regardless of arity, or a call with arity, such as String.split/2, to count all
calls to that exact module, function and arity.

Caveats

You should be aware the profiler is stopped as soon as the code has finished running. This
may need special attention, when: running asynchronous code as function calls which were
called before the profiler stopped will not be counted; running synchronous code as long
running computations and a profiler without a proper MFA trace pattern or filter may
lead to a result set which is difficult to comprehend.

Other caveats are the impossibility to call count trace BIFs, since breakpoints can
only be set on BEAM code; functions calls performed by :cprof are not traced; the
maximum size of a call counter is equal to the host machine's word size
(for example, 2147483647 in a 32-bit host).