Intel AS/400 RISC Server - Manual (Page 315)

20.2 General Performance Guidelines -- Effects of Compilation
In general, the higher the optimization, the less easy the code will be to debug. It may also be the case
that the program will do things that are initially confusing.
In-lining
For instance, suppose that ILE Module A calls ILE Module B. ILE Module B is a C program that does
allocation (malloc/free in C terms). However, in the right circumstances, compiler optimization will
"inline" Module B. In-lining means that the code for B is not called, but it is copied into the calling
module instead and then further optimized. So, for at least Module A, then, the "in-lined" Module B will
cease to be an individual compiled unit and simply have its code copied, verbatim, into A.
Accordingly, when performance traces are run, the allocation activity of Module B will show up under
Module A in the reports. Exceptions would also report the exception taking place in Module A of
Program X.
In-lining of "final" methods is possible in Java as well, with similar implications.
Optimization Levels
Most of the compilers and Java support a reasonably compatible view of optimization. That is, if you
specify OPTIMIZE(10) in one language, it performs similar levels of optimization in another language,
including Java's CRTJVAPGM command. However, these things can differ at the detailed level. Consult
the manuals in case of uncertainty.
Generally:
v
OPTIMIZE(10) is the lowest and most debuggable.
v
OPTIMIZE(20) is a trade-off between rapid compilation and some minimal optimization
v
OPTIMIZE(30) provides a higher level of optimization, though it usually avoids the more
aggressive options. This level can debug with difficulty.
v
OPTIMIZE(40) provides the highest level of optimization. This includes sophisticated analysis,
"code motion" (so that the execution results are what you asked for, but not on a
statement-by-statement basis), and other optimizations that make debugging difficult. At this level
of optimization, the programmer must pay stricter attention to the manuals. While it is surprisingly
often irrelevant in actual cases, many languages have specific definitions that allow latitude to
highly optimized compilers to do or, more importantly, "not do" certain functions. If the coder is
not aware of this, the code may behave differently than expected at high optimization levels.
LICOPT
A new option has been added to most ILE Languages called LICOPT. This allows language specific
optimizations to be turned on and off as individual items. A full description of this is well beyond the
scope of this paper, but those interested in the highest level of performance and yet minimizing potential
difficulties with specific optimization types would do well to study these options.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 20 - General Tips and Techniques 315