This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs. |
You can select a topic from this diagram:
This chapter shows you how to use the application profiler.
The QNX Application Profiler perspective lets you examine the overall performance of programs, no matter how large or complex, without following the source one line at a time. Whereas a debugger helps you find errors in your code, the Application Profiler helps you pinpoint "sluggish" areas of your code that could run more efficiently.
The QNX Application Profiler perspective.
The Application Profiler lets you perform:
The Application Profiler takes "snapshots" of your program's execution position every millisecond and records the current address being executed. By sampling the execution position at regular intervals, the tool quickly builds a summary of where the system is spending its time in your code.
With statistical profiling, you don't need to use instrumentation, change your code, or do any special compilation. The tool profiles your programs nonintrusively, so it doesn't bias the information it's collecting.
Note, however, that the results are subject to statistical inaccuracy because the tool works by sampling. Therefore, the longer a program runs, the more accurate the results.
If you build your executables with profiling enabled, the Application Profiler can provide call-pair information (i.e. which functions called which). When you build a program with profiling enabled, the compiler inserts snippets of code into your functions in order to report the addresses of the called and calling functions. As your program runs, the tool produces an exact count for every call pair.
The IDE lets you examine profiling information from a gmon.out file produced by an instrumented application. The tool gives you all the information you'd get from the traditional gprof tool, but in graphical form. You can examine gmon.out files created by your programs, whether you built them using the IDE or the qcc -p command. For more on the gprof utility, go to www.gnu.org; for qcc, see the Utilities Reference.
Whether you plan to do your profiling in real time or postmortem (using a gmon.out file), you should build your programs with profiling enabled before you start a profiling session.
This section includes these topics
If you already have a gmon.out file, you're ready to start a postmortem profiling session. |
Although you can profile any program, you'll get the most useful results by profiling executables built for debugging and profiling. The debug information lets the IDE correlate executable code and individual lines of source; the profiling information reports call-pair data.
This tables shows the application profiling features that are possible with the various build variants:
Feature | Release version | Debug version | Release v. & profiling | Debug v. & profiling |
---|---|---|---|---|
Call pairs | No | No | Yes | Yes |
Statistical sampling | Yes (function level) | Yes | Yes (function level) | Yes |
Line profiling | No | Yes | No | Yes |
Postmortem profiling | No | No | Yes | Yes |
To build executables with debug information and profiling enabled:
The Application Profiler uses the information in the debuggable executables to correlate lines of code in your executable and the source code. To maximize the information you get while profiling, use executables with debug information for both running and debugging. |
To build a Standard Make project for profiling, compile and link
using the -p option. For example, your Makefile
might have a line like this:
CFLAGS=-p CXXFLAGS=-p LDFLAGS=-p |
To run and profile a process, with qconn on the target:
To produce full profiling information with function timing data, the
application needs to be run as root. This is the case when
running through qconn.
If the application is run as a normal user, the profiler can only generate call chain information. |
To profile a process that's already running on your target:
Your running application won't generate call-pair information unless
you ran it with the QCONN_PROFILER environment variable
set to /dev/profiler.
If you're launching the application from the IDE, add QCONN_PROFILER to the Environment tab of the launch configuration's Properties dialog. If you're running the application from the command-line, you can simply add QCONN_PROFILER to your shell environment, or the application's command-line: QCONN_PROFILER=/dev/profile ./appname |
The IDE lets you profile your program after it terminates, using the traditional gmon.out file. Postmortem profiling doesn't provide as much information as profiling a running process:
Profiling a gmon.out file involves three basic steps:
The IDE lets you store your profiling information in the directory of your choice using the PROFDIR environment variable.
To gather profiling information:
You must have the QNX Application Profiler tool disabled in your launch configuration. |
You can bring existing gmon.out files that you created outside the IDE into your workspace from your target system.
To import a gmon.out file into your workspace:
To start the postmortem profiling session:
The Application Profiler view (Window-->Show View-->Other...-->QNX Application Profiler-->Application Profiler) lets you control multiple profiling sessions simultaneously. You can:
The Application Profiler view displays the following as a hierarchical tree for each profiling session:
Session item | Description | Possible icons |
---|---|---|
Launch instance | Launch configuration name and launch type (e.g. prof201 [C/C++ QNX QConn (IP)]) | |
Profiled program | Project name and start time (e.g. prof201 on localhost pid 4468773 (3/4/03 12:41 PM)) | |
Application Profiler instance | Program name and target computer (e.g. Application Profiler Attached to: prof201 <4468773> on 10.12.3.200) | |
Executable | ||
Shared libraries | ||
DLLs | ||
Unknown |
To choose which executable or library to display information for in the QNX Application Profiler perspective:
In the Application Profiler view, click one of the following:
|
To terminate an application running on a target:
To clear old launch listings from this view, click the Remove All Terminated Launches button (). |
To disconnect from an application running on a target:
To clear old launch listings from this view, click the Remove All Terminated Launches button (). |
For each item you select in the Application Profiler view, other views within the QNX Application Profiler perspective display the profiling information for that item:
This view: | Shows: |
---|---|
Application Profiler editor | usage by line |
Sampling Information | usage by function |
Thread Processor Usage | usage by thread |
Call Information | Call counts |
The Application Profiler editor lets you see the amount of time your program spends on each line of code and in each function.
To open the editor:
You may get incorrect profiling information if you change your source after compiling because the Application Profiler editor relies on the line information provided by the debuggable version of your code. |
The Application Profiler editor displays a bar graph on the left side. The bars are color coded:
To view quantitative profiling values:
In the Application Profiler editor, hover the pointer over a colored bar. The CPU usage appears, displayed as a percentage and a time: |
The Sampling Information view shows a flat profile of the item that's currently selected in the Application Profiler view. You can examine profiling information for programs, shared libraries, and DLLs:
The view lists all the functions called in the selected item. For each function, this view displays:
If you select a program compiled for profiling, the view also displays:
To see your function usage:
To reset the counters in the Time since last reset(s) column:
Click the Reset Sample counts button () in the Sampling Information view's title bar. |
The Thread Processor Usage view displays the CPU usage (in seconds and as a percentage of your program's total time) for each thread of the item that's currently selected in the Application Profiler view:
You can use this information to:
To see your thread usage:
For the item that's currently selected in the Application Profiler view, the Call Information view shows your call counts in three panes:
To display your call counts:
The Call Pairs pane shows you where every function was called from as well as the call-pair count, i.e. the number of times each function called every other function.
The Call Graph pane shows you a graph of the function calls. Your selected function appears in the middle, in blue. On the left, in yellow, are all the functions that called your function. On the right, also in yellow, are all the functions that your function called.
To see the calls to and from a function:
Click a function in:
|
You can display the call graph only for functions that were compiled with profiling enabled. |
The Call Pair Details pane shows the information about the function you've selected in the Call Graph pane. The Caller and Call Count columns show the number of times each function called the function you've selected.
The Called and Called Count columns show the number of times your selected function called other functions. This pane shows only the functions that were compiled with profiling. For example, it doesn't show calls to functions, such as printf(), in the C library.