The recommended performance enhancement method for optimizing applications consists of several phases. When attempting to identify performance issues, move through the following general phases in the order presented:
The following figure shows the methodology phases and their relationships, along with some recommended tools to use in each appropriate phase.
In general, the methodology can be summarized by the following two statements:
Make small changes and measure often.
If you approach a point of diminishing return and can find no other performance issues, stop optimizing.
Use tools to measure where performance bottlenecks occur; do not waste time guessing. Using the right tools for analysis provides an objective data set and baseline criteria to measure implementation changes and improvements introduced in the other stages. The VTune™ Performance Analyzer is one tool you can use to gather performance data and quickly identify areas where the code runs slowly, executes infrequently, or executes too frequently (hotspots) when measured as a percentage of time taken against the total code execution.
See Using Intel Performance Analysis Tools and Using Tuning Tools and Strategies for more information about some tools and strategies you can use to gather performance data.
Determine if the data meet your expectations about the application performance. If not, choose one performance problem at a time for special interest. Limiting the scope of the corrections is critical in effective optimization.
In most cases, you will get the best results by resolving hotspots first. Since hotspots are often responsible for excessive activity or delay, concentrating on these areas tends to resolve or uncover other performance problems that would otherwise be undetectable.
Use the VTune™ Performance Analyzer, or some other performance tool, to discover where to concentrate your efforts to improve performance.
As in the analysis phase, limit the focus of the work. Concentrate on generating alternatives for the one problem area you are addressing. Identify and use tools and strategies to help resolve the issues. For example, you can use compiler optimizations, use Intel® Performance Library routines, or use some other optimization (like improved memory access patterns, reducing or eliminating division or other floating-point operations, rewriting the code to include intrinsics or assembly code, or other strategies).
See Applying Performance Enhancement Strategies for suggestions.
While optimizing for the compiler and source levels, consider using the following strategies in the order presented:
Use available supported compiler options. This is the most portable, least intrusive optimization strategy.
Use compiler directives embedded in the source. This strategy is not overly intrusive since the method involves including a single line in code, which can be ignored (optionally) by the compiler.
Attempt manual optimizations.
The preferred strategy within optimization is to use available compiler intrinsics. Intrinsics are usually small single-purpose built-in library routines whose function names usually start with an underscore (_).
If intrinsics are not available, try to manually apply the optimization. Manual optimizations, both high-level language and assembly, are more labor intensive, more prone to error, less portable, and more likely to interfere with future compiler optimizations that become available.
As with the previous phases, limit the focus of the implementation. Make small, incremental changes. Trying to address too many issues at once can defeat the purpose and reduce your ability to test the effectiveness of your enhancements.
The easiest enhancements will probably involve enabling common compiler optimizations for easy gains. For applications that can benefit from the libraries, consider implementing Intel® Performance Library routines that may require some interface coding.
If you have limited the scope of the analysis and implementation, you should see measurable differences in performance in this phase. Have a target performance level in mind so you know when you have reached an acceptable gain in performance.
Use a consistent, reliable test that reports a quantifiable item such as seconds elapsed, frames per second, etc., to determine if the implementation changes have actually helped performance.
If you think you can make significant improvement gains or you still have other performance issues to address, repeat the phases beginning with the first one: gather performance data.