Restrictions and Limitations of PBO

This section describes restrictions and limitations you must be aware of when using Profile-Based Optimization. This section discusses the folowing topics:

“Temporary Files” (page 214)

“Source Code Changes and PBO” (page 214)

“Profile-Based Optimization (PBO) and High-Level Optimization (HLO)” (page 214)

“I-SOM File Restrictions” (page 215)

NOTE: PBO calls malloc() during the instrumentation (+I) phase. If you replace libc malloc(3C) calls with your own version of malloc(), use the same parameter list (data types, order, number, and meaning of parameters) as the HP version. (For information on malloc(), see malloc(3C).)

Temporary Files

The linker does not modify I-SOM files. Rather, it compiles, instruments, and optimizes the code, placing the resulting temporary object file in a directory specified by the TMPDIR environment variable. If PBO fails due to inadequate disk space, try freeing up space on the disk that contains the $TMPDIR directory. Or, set TMPDIR to a directory on a disk with more free space.

Source Code Changes and PBO

To avoid the potential problems described later in this section, PBO must be used only during the final stages of application development and performance tuning, when source code changes are the least likely to be made. Whenever possible, an application should be re-profiled after source code changes have been made.

What happens if you attempt to optimize a program using profile data that is older than the source files? For example, this can occur if you change source code and recompile with +P, but don't gather new profile data by re-instrumenting the code.

In that sequence of events, optimizations are still performed. However, full profile-based optimizations will be performed only on those procedures whose internal structure has not changed since the profile data was gathered. For procedures whose structure has changed, the following warning message is generated:

ucomp warning: Code for name changed since profile database file flow.data built. Profile data for name ignored. Consider rebuilding flow.data.

Note that it is possible to make a source code change that does not affect the control flow structure of a procedure, but which does significantly affect the profiling data generated for the program. In other words, a very small source code change can dramatically affect the paths through the program that are most likely to be taken. For example, changing the value of a program constant that is used as a parameter or loop limit value may have this effect. If the user does not re-profile the application after making source code changes, the profile data in the database does not reflect the effects of those changes. Consequently, the transformations made by the optimizer can degrade the performance of the application.

Profile-Based Optimization (PBO) and High-Level Optimization (HLO)

High-level optimization, or HLO, consists of a number of optimizations, including inlining, that are automatically invoked with the +O3 and +O4 compiler options. (Inlining is an optimization that replaces each call to a routine with a copy of the routine's actual code.) +O3 performs HLO on each module while +O4 performs HLO over the entire program and removes unnecessary ADDIL instructions. Since HLO distorts profile data, it is suppressed during the instrumentation phases of PBO.

214 Improving Your Application Performance

Page 214
Image 214
HP UX Software Transition Kit (STK) manual Restrictions and Limitations of PBO, Source Code Changes and PBO