This document covers the following topics:
Best performance is achieved when you use the data formats packed numeric (P) and integer (I4) in arithmetic operations.
Avoid converting data between the formats packed numeric (P), unpacked numeric (N), integer (I), and floating point (F), as this causes processing overhead even with optimized code.
As there is no interpretation overhead with optimized code, the differences between the various data formats become much more prominent: with optimized code the performance improvement gained by using format P instead of N, for example, is even higher than with normal code.
A = A + 1
In the above numeric calculation
with non-optimized code, format P executes approximately 13 % faster than format N.
with optimized code, however, format P executes approximately 56 % faster than format N.
The performance gain which would be achieved by applying the Natural Optimizer Compiler to this simple statement is
with unpacked operands (N): 8 times faster
with packed operands (P): 15 times faster
Array range operations, such as
MOVE A(*) TO B(*)
are executed more efficiently than if the same function were programmed
using a FOR statement processing loop. This is also true for
optimized code.
When indexes are used, integer format I4 should be used to achieve optimum performance.
We recommend that you adjust the length of the alphanumeric constant to the length of the variable, when moving an alphanumeric constant to an alphanumeric variable (format A), or when comparing an alphanumeric variable with an alphanumeric constant. This will significantly speed up operation, for example:
A(A5):='XYZAB' ... IF A = 'ABC ' THEN ...
is faster than
IF A = 'ABC' THEN ...
When using the DECIDE ON statement with a system variable,
array or parameter operand1, it is more
efficient to move the value to a scalar variable of the same type and length
defined in the LOCAL storage section.
When using numeric constants in assignments or arithmetic operations, try to force the constants to have the same type as the operation.
Any numeric constant with or without a decimal but without an exponent is compiled to a packed number having the minimum length and precision to represent the value, unless the constant is an array index or substring starting position or length, in which case it becomes a four-byte integer (I4). This rule applies irrespective of the variable types participating in the operation.
Operations containing floating point will be executed in floating
point. Add E00 to numeric values to force them to be floating
point, for example:
ADD 1E00 to F(F8)
Operations not containing floating point, but containing packed
numeric, unpacked numeric, date or time variables will be executed in packed
decimal. For ADD, SUBTRACT and IF, force
numeric constants to have the same number of decimal places as the variable
with the highest precision by adding a decimal place and trailing zeros, for
example:
ADD 1.00 TO P(P7.2)
This technique is unnecessary for MULTIPLY and
DIVIDE.
To ease the optimization process, try to keep all scalar references at the front of the data section and all array references at the end of the data section.
The Natural Optimizer Compiler contains an algorithm to enhance the performance even further. In terms of performance, a statement will differ depending on the types of operands. The statement will execute more slowly if one or more of the operands is a parameter, array or scalar field of Type N (numeric) or combinations of these operands. The NOC analyzes the program flow and determines which variables with one or more of these characteristics are read two or more times without being written to. It then moves the value of each variable to a temporary cache area where it can be accessed quickly under the following conditions:
The variable is accessed often but seldom modified and
The variable is an array of any type or a scalar field of Type N (numeric).
Most suitable for variable caching are programs with long sequences that repeatedly access the same variable, in particular if the variable is an array. Variable caching then avoids complex and recurring address computation.
The example program displayed below demonstrates the advantage of
variable caching. Cataloged with NODBG (see below) and
CACHE=ON, executing this program in a test environment took 47 %
of the time required to execute the program with NODBG and
CACHE=OFF. Cataloging the program with CACHE=ON,
reduces the code generated by the NOC from 856 bytes to 376 bytes.
DEFINE DATA LOCAL 1 ARR(N2/10,10,10) 1 I(I4) INIT <5> 1 J(I4) INIT <6> 1 K(I4) INIT <7> END-DEFINE DECIDE ON EVERY ARR(I,J,K) VALUE 10 IGNORE VALUE 20 IGNORE VALUE 30 IGNORE VALUE 40 IGNORE VALUE 50 IGNORE VALUE 60 IGNORE VALUE 70 IGNORE VALUE 80 IGNORE VALUE 90 IGNORE NONE IGNORE END-DECIDE
 |
Warning: If the content of a cached variable is modified with the command MODIFY VARIABLE of the Natural
Debugger, only the
content of the original variable is modified. The cached value (which may still
be used in subsequent statements) remains unchanged. Therefore, variable
caching should be used with great care if the Natural Debugger is used. See
also the Natural Debugger documentation. |
Once a program has been thoroughly tested and put into production, you
should catalog the program with the NODBG option as
described in the section Optimizer
Options. Without debug code, the optimized statements will
execute from 10% to 30% faster.
The code to facilitate debugging is removed when this option is
specified, even with INDX or OVFLW options turned
on.