OPTIMIZING

Optimizing application code is a popular topic. Ironically, most of the optimizing has focused more on the performance of the compiler and not on application programs. Application programmers should, of course, be concerned with the application's performance more than the compiler's thoroughness.

With RPG, using indicators can lead to poor application performance. A conditioning indicator entry on the calculation specification generates one "compare" instruction for each indicator used. Therefore, each indicator used to condition an operation generates an independent compare instruction.

You could surmise that the use of RPG indicators is not good for performance. That's actually true. The modern RPG programmer avoids the use of indicators and, in their place, uses the IF, DOW, DO, DOU, FOR, CASxx, and SELECT/WHEN operations to control program flow.

Most operation codes generate a corresponding machine instruction. A MOVE generates a COPY instruction, an ADD generates an add-numeric instruction, a COMP generates a compare instruction, an IF generates a compare instruction, and so on.

Subscript fields (i.e., arrays and multiple occurring data structures) generate additional overhead. Therefore, when the same array element is used throughout a routine—moving the array element to a field—then performing the operations on the field can improve runtime performance.

Some operations, such as the SQRT, LOOKUP, and dynamic CALL operations, generate entire subroutines containing dozens of machine instructions. For example, if a program uses the dynamic CALL operation to evoke an external program at eight different locations, the CALL operation is inserted into the program at each of those eight locations. The compiler generates the same CALL-related instructions—eight times. This can lead to larger program sizes.

The dynamic CALL can be placed into a subroutine and performed through the EXSR (Perform Subroutine) or CASxx (Compare and Perform Subroutine) operations. The subroutine would then be called each time the subprogram is needed. The code needed to call the subprogram is not used in multiple locations. Therefore, the program is smaller and provides fewer chances for programming errors.

The overhead for a call to an RPG subroutine is minimal. The overhead for a call to an external program is huge. Program modularity, however, must be taken into consideration. Both in size and performance, using a subprocedure can be a good compromise, and so can a bound call (through the CALLB operation) to another program.

Other considerations for program speed are the use of MULT (multiply) and DIV (divide) operations. On most computers, these instructions are transients that can cause the machine to "burp" slightly whenever they are performed. For example, the MOVE, ADD, and SUB operations run several times faster than the MULT, DIV, and SQRT operations. The number of times an operation code is performed per transaction also must be taken into consideration. If the code is only performed once or twice per transaction, there is no need to worry about how fast a specific operation code runs.

As new compiler architectures are introduced into the RPG language, the issue of optimization in specific areas is being reduced. Compilers, or rather optimizers, are getting more and more intelligent. As they become smarter, the optimizer is performing more of the optimization traditionally performed by hand by a programmer.