Debugging/Profiling

From ArchWiki

Due to performance regressions, unoptimized new features or simply unknown factors affecting performance, it may be necessary to profile an application. According to Wikipedia:

In software engineering, profiling ("program profiling", "software profiling") is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. Most commonly, profiling information serves to aid program optimization, and more specifically, performance engineering.

Installation

Install perf.

Getting debug symbols

In order to get interpretable results, debugging symbols for the application you are debugging are mandatory. See Debugging/Getting traces#Manually getting debug info. perf does not support debuginfod yet and thus the debugging symbols must be obtained manually.

Should the application be profiled or otherwise debugged without debugging symbols, there will only be pointers instead of actual function names, which are quite useless.

Usage

Just as with gdb, the application will be run within perf.

Note: It may be necessary to adjust the profiling frequency using -F. Since 2012-05-22 it defaults to 4000. A higher value will cause more load. While the default is fine for most cases, you may want to increase the value further for programs which have a very short runtime or decrease it if the program will be running a long time. Also keep the system load in mind, as a high load will cause sampling overhead and hide the actual bottleneck that is being debugged. See perf-record(1).
$ perf record -g -- command

This will record the data to perf.data. After the program is finished, display the results with:

$ perf report --stdio

For a prettier display, consider using cargo-flamegraph.

If reporting a bug to upstream, submit the perf.data file.

See also