# Use the Profiler
The profiler is used after an application is executed on the
simulator. The simulator generates one or more data files containing
profiling information while it executes the target application. After
the simulation is completed, the profiler inputs the generated
profile data files and displays the profiling information.
**Using the profiler**
The profiler operates as a stand-alone application. It displays two
types of profile information:
- **Flat profile information** – The number of cycles executed in each
function.
- **Call-graph information** – Which functions a given function called,
which functions called a given function, and how many times each
function was called.
All profiling information is displayed as text data, which can be
redirected to an output file.
## Create the profile data file
Before an application can be profiled, you must create a profile data
file by simulating the application with the command option,
--profile.
In some cases the profile data is distributed across multiple profile
data files:
- When a program is a multi-threaded stand-alone program, its profile
data files are named for each hardware thread (for example, gmon.t\_0,
gmon.t\_1, …).
- When a program is a multi-threaded RTOS application, its profile data
files are named for each software thread (for example, gmon.name1,
gmon.name2, …).
In these cases, all of the profile data files must be specified on
the profiler command line. To simplify this effort, the relevant
command option accepts wild-card characters (for example, gmon\*).
For more information on profile data files, see the *HexagonSimulator User Guide*.
## Start the profiler
To start the profiler from a command line, enter the following:
hexagon-gprof [executable_files...] [profile_data_files...]
[> output_file]
Copy to clipboard
### Executable files
The profiler optionally accepts one or more executable program files
as input files. The default is a.out.
The profiler uses the symbolic data in these files to create the
profiling information.
Note
When profiling an RTOS application system, each executable
file in the system must be specified as an input file.
### Profile data files
The profiler optionally accepts one or more profile data files as
input files. The default is gmon.out.
All of the profile data files for the application must be specified.
Multiple profile data files can be specified using wild-card
characters (such as gmon\*).
Note
Processing multiple profile data files can be
memory-intensive.
### Output file
The profiler writes all the profiling information it generates to the
standard output. The information can be optionally redirected to an
output file.
## Profile data
The profiler displays two types of profile information:
- **Flat profile information** – The number of cycles executed in each
function.
- **Call-graph information** – Which functions a given function called,
which functions called a given function, and how many times each
function was called.
### Flat profile
The *flat profile* lists the number of thread cycles executed in each
function in a thread, with the list sorted by self cycles. For
example:
Flat profile for t\_3234404640\_88:
| **% time** | **cumulative cycle(s)** | **self cycle(s)** | **calls** | **self Mc/call** | **total Mc/call** | **name** |
| --- | --- | --- | --- | --- | --- | --- |
| 28.01 | 693 | 693 | 4 | 0.17 | 0.46 | h264FrontEnd\_CoreTaskHandler |
| 23.00 | 1262 | 569 | 5 | 0.11 | 0.13 | VBUF\_New |
| 14.23 | 1614 | 352 | 1 | 0.35 | 2.29 | h264FrontEnd\_ThreadProc |
| 4.20 | 1718 | 104 | 1 | 0.10 | 0.16 | h264BatchDecoder\_TryAcquireBatchServer |
| 3.88 | 1814 | 96 | 10 | 0.01 | 0.01 | qurt\_mutex\_lock |
| 3.76 | 1907 | 93 | 4 | 0.02 | 0.03 | VBUF\_Release |
| 2.79 | 1976 | 69 | 5 | 0.01 | 0.02 | qurt\_anysignal\_wait |
| 2.18 | 2030 | 54 | 4 | 0.01 | 0.01 | h264\_dec\_query\_input |
| 2.18 | 2084 | 54 | 1 | 0.05 | 0.06 | qurt\_anysignal\_init |
| 2.18 | 2138 | 54 | 0 | | | qurt\_trampoline |
| 2.18 | 2192 | 54 | 2 | 0.03 | 0.03 | qurt\_rmutex\_lock |
| 2.18 | 2246 | 54 | 1 | 0.05 | 2.36 | qurt\_elite\_thread\_stub(void\*) |
| 2.02 | 2296 | 50 | 1 | 0.05 | 0.05 | save\_r16\_through\_r23 |
| 1.78 | 2340 | 44 | 10 | 0.00 | 0.00 | qurt\_mutex\_unlock |
| 1.09 | 2367 | 27 | 5 | 0.01 | 0.01 | qurt\_anysignal\_clear |
| 0.93 | 2390 | 23 | 4 | 0.01 | 0.01 | qurt\_anysignal\_wait\_fatal |
| 0.65 | 2406 | 16 | 1 | 0.02 | 0.10 | qurt\_elite\_queue\_pop\_front |
| 0.57 | 2420 | 14 | 1 | 0.01 | 0.02 | restore\_r16\_through\_r23\_and\_deallocfr |
| 0.49 | 2432 | 12 | 8 | 0.00 | 0.00 | qurt\_anysignal\_get |
| 0.49 | 2444 | 12 | 4 | 0.00 | 0.00 | h264\_dec\_query\_output |
| 0.32 | 2452 | 8 | 2 | 0.00 | 0.00 | qurt\_rmutex\_unlock |
| 0.16 | 2456 | 4 | 1 | 0.00 | 0.00 | restore\_r16\_through\_r17\_and\_deallocf |
| 0.12 | 2459 | 3 | 1 | 0.00 | 0.00 | qurt\_thread\_set\_ugp |
| 0.12 | 2462 | 3 | 1 | 0.00 | 0.00 | qurt\_futex\_alloc\_wait\_queue |
| 0.12 | 2465 | 3 | 1 | 0.00 | 0.00 | qurt\_get\_thread\_id\_in\_tcb |
| 0.08 | 2467 | 2 | 1 | 0.00 | 0.00 | qurt\_thread\_get\_id |
| 0.04 | 2468 | 1 | 1 | 0.00 | 0.00 | VBUF\_GetInfo |
**Values contained in the flat profile**
| **Field** | **Description** |
| --- | --- |
| % time | Percentage of the total number of cycles spent in a function |
| cumulative cycle(s) | Running total of cycles that includes the cycles for a specific function and all the functions above it in the list |
| self cycle(s) | Number of cycles spent in a function on the current thread |
| calls | Total number of times a function was called on the current thread |
| self Mc/call | Average number of cycles per function call |
| total Mc/call | Average number of self cycles plus descendant cycles per function call |
| name | Function name |
### Call graph
The *call graph* lists how many cycles were executed in each function
plus its callers and callees, with the list sorted by self plus child
cycles. For example:
Call graph for t\_3234404640\_88:
| **index** | **% time** | **self** | **children** | **called** | **name** |
| --- | --- | --- | --- | --- | --- |
| [1] | 100.0 | 54
VBUF\_Release [2] |
**Values contained in the call graph**
| **Field** | **Description** | |
| --- | --- | --- |
| index | Caller | Not shown |
| | Self | Index value of the current function
For cross-reference purposes, this value is also displayed after the name on each line in the column field |
| | Callee | Not shown |
| % time | Caller | Not shown |
| | Self | Percentage of cycles that a function and its callees executed on the current thread |
| | Callee | Not shown |
| self | Caller | Estimated number of cycles executed by a function when called by the current caller |
| | Self | Total number of cycles executed by a function on the current thread |
| | Callee | Total number of cycles executed by the called function on the current thread |
| children | Caller | Estimated number of cycles executed by the callees of a function when called by the current caller |
| | Self | Total number of cycles executed by the functions called from the current function |
| | Callee | Total number of cycles executed by the called function’s children |
| called | Caller | Total number of times the calling function called a function, followed by the total number of times the function was called |
| | Self | Total number of times a function was called on the current thread |
| | Callee | Total number of times the called function was called by the current function, followed by the total number of times the called function was called |
| name | Caller | Name of a calling function followed by its index value in brackets (such as [1]) |
| | Self | Name of a function followed by its index value in brackets |
| | Callee | Name of a called function followed by its index value in brackets |
## Profiling accuracy
The profiler can only create estimated values for the following
profile data:
- Children cycle counts
- Cycle counts for function callers and callees
Because the profiler does not receive this information directly from
the profile data, it must assume that for a given function F, the
average number of cycles executed in each call to F is not correlated
to the functions that call F.
For example, if function F1 executes for a total of 100 cycles, and
one quarter of the calls to F1 originate from function F2, the
profiler assumes that F1 contributes 25 cycles to F2’s children cycle
count.
This assumption is invalid if, for instance, F1 returns immediately
after receiving a specific argument value, and F2 is the only
function that ever passes that value to F1.
You are responsible for being aware of such cases and interpreting
the profiling information appropriately.
Last Published: Oct 06, 2026
[Previous Topic
Feedback](https://docs.qualcomm.com/bundle/publicresource/80-N2040-29/topics/gprof-profiler-ug-overview.md) [Next Topic
Profile data utilities](https://docs.qualcomm.com/bundle/publicresource/80-N2040-29/topics/profile-data-utilities.md)