TNS/R Native Application Migration Guide
TNS/R Native Application Migration Guide—523745-001
2-1
2
Developing a Migration Strategy
This section describes the decisions you must make to migrate a program to native
mode, including:
•
Determining Which Programs to Migrate
•
Preparing Programs for Migration on page 2-2
•
Planning System Resources on page 2-2
•
Maintaining Common Source Code for TNS and Native Compilers on page 2-3
•
Determining Optimization Levels on page 2-4
•
Determining Data Alignment on page 2-5
•
Tuning the Performance of Native Programs on page 2-6
Determining Which Programs to Migrate
Determining which programs to migrate to native mode is similar to determining which
programs to accelerate:
•
If CPU performance is not an issue (for example, the program is I/O-bound), you
gain some but not much measurable performance by native-compiling the program
instead of accelerating the program with the Accelerator. Where CPU performance
is an issue, there is great advantage to native-compiling: programs usually run
significantly faster when native-compiled.
•
If your program consists mainly of calls on system code, you do not gain much
additional performance by native-compiling the program itself. Much of the
performance-critical and heavily-used HP system code has been native-compiled.
•
If your program uses large amounts of memory, is very recursive, or makes many
function calls with a large number of local variables, you often gain additional
performance by native compiling the program instead of accelerating the program.
The native process architecture supports a much larger and more efficient process
heap and stack.
•
If you want to compile and link your program on a PC as part of either ETK or TDS,
you must migrate to native mode.
You can use the Measure system performance-analysis tool to determine which
programs can be significantly improved by native-compiling.When measuring program
performance, select a measurement window that coincides with some representative
portion of the system workload, usually the system’s peak time. For further verification,
take and compare multiple measurements to create a level of confidence with the data
collected.