After you have successfully debugged your program, you can evaluate its performance with the Sampling Analyzer, a program designed to help you tune application performance, including memory allocation. The Sampling Analyzer measures and graphically displays your application's performance profile and suggests ways to improve performance. Its special data collection instrumentation eliminates the need to continually compile and link an application--any program that has been compiled can be analyzed.
The performance data you can examine in the Sampling Analyzer include:
User time. Time spent executing user program instruction
Fault time. Time required to service fault-driven memory activities, classified into text and data page faults
I/O time. Time the operating system spent waiting for input/output operations, such as writing to a disk or tape
System time. Time the operating system spent executing system calls
Trap time. Time spent in executing traps (automatic exceptions or memory faults)
Lock wait time. Time spent waiting for lightweight process locks
Sleep time. Time the program spent inactive, waiting for a wake up signal
Suspend time. Time spent temporarily halted (includes time spent in the debugger during breakpoint and the time used by the Sampling Collector to gather data)
Idle time. Time spent waiting to run while the system was busy
Function sizes. Sizes of functions in the program
Module sizes. Sizes of modules in the program
Segment sizes. Sizes of segments in the program
Memory usage. Memory page reference and modification data
Resource usage. Information about the system resources that are used by the program, including major and minor page faults, process swaps, number input and output blocks, number of messages sent and received, number of signals handled, number of voluntary and involuntary context switches, number of system calls, number of characters of input/output, and number of working set memory pages
The debugger serves as the data-gathering front end for the Sampling Analyzer. You can control the data collection process with the Sampling Collector window in dbx or the debugger while your program is running. You can collect data only between breakpoints, or you can limit data collection to a particular part of the program. The program run in which you collect data is known as an experiment, and the data file created by the Collector is called the experiment record. You then use the Sampling Analyzer to identify performance bottlenecks in the collected data.
Performance tuning and runtime checking are mutually exclusive processes. You can perform only one or the other at a time. The information you receive from tuning your application can be adversely affected if you try to perform runtime checking simultaneously.
Test your hypotheses about a program's behavior by focusing on the areas where performance problems occur. To rebuild your programs with improved performance, use the Sampling Analyzer to identify areas where you can improve ordering for loading functions into the program's address space. In some cases, the Sampling Analyzer can improve performance automatically by creating a mapfile that instructs the linker to remap functions in memory more efficiently.
Performance analysis tools provide a range of analysis levels, from simple timing of a command to a statement-by-statement analysis of a program. While a flat profile can provide valuable data for performance improvements, sometimes the data is not sufficient to point out exactly where improvements can be made. You can obtain a more detailed analysis by using the call graph profile to identify which modules are called by other modules, and which modules call other modules.