Certain operations can cause fairly long sequences of generated code. Some of these include:
- || (concatenation)
- || (concatenation) involving operands of non-constant length and/or non-constant starting position.
- Built-ins
- For certain Built-ins, such as VERIFY, TRANSLATE, etc..., that build large tables (typically 256 bytes), avoid certain run-time
evaluated arguments; for example, in the following example of TRANSLATE, which converts all commas and periods to blanks,
the first usage is much better performing than the second:
- target = TRANSLATE(source, ' ', ',.');
- target = TRANSLATE(source, two_blanks, comma_period); DCL (two_blanks init(''), comma_period init(',.')) char(2) static;
- Operations on differing operand types
- Operations on differing operand types; for example:
DCL f fixed bin(31) init(1111);
DCL c char(8);
c = ‘1234’;
f = f + c;
Require a conversion from character to fixed binary before the addition can take place.
Another example:
c = c + f;
Requires
c to be converted from a character (to fixed binary), and then converted back after the addition. In such cases, declare
c as fixed bin(31);
- Iterative DO statement
- In an iterative DO statement, if the BY value is negative, the control variable is decremented by the BY value until it is
<= the TO value. This means that unless the BY value is a signed constant, the compiler must generate code that can handle
a decrementing as well an incrementing loop. When possible, use a constant value for BY.
- Bit-string operations[1]
- The use of a bitwise AND in PL/I programs can have a positive effect on performance when the target and the two operands of
the bitwise AND both:
- Have identical attributes and lengths
- Are 32 bits in length or less
In this case, the compiler generates inline code that performs the AND much faster than a call to a library routine. Even
in the case where a PL/I RTS library routine has to be called to perform the bitwise AND, performance is much faster when
the attributes match.
However, when the target and the two operands of the bitwise AND have inconsistent attributes and lengths and/or are more
than 32 bits in length, then the program calls a PL/I RTS Library routine to do the proper conversion instead of generating
inline code. The call requires more interaction in terms of conversions, fill bits, etc., significantly slowing processing
time. This performance hit is particularly noticeable on Intel platforms where the
-bitsltr compile option is in effect.
When performance is a consideration and when possible, we recommend that you adjust your code such that both the target and
the two operands of the bitwise AND have identical lengths and attributes. Consider setting the ALIGNED attribute as it is
the fastest.
Note: The default attribute for scalar bit strings is UNALIGNED. See
Bit-String Data for details.
The performance difference between z/OS and distributed platforms is determined by the following factors:
- To emulate bigendian bit strings on Intel requires that the bits be flipped from left to right, which requires an injection
of code into both the run-time system and the program.
- z/OS uses different machine operation codes for bitwise ANDs, and can only process up to 256 BYTES in a single AND (opcode
NC, AND Characters). However, Intel platforms impose a limit of 4 bytes (32 bits) on a machine code AND, which is more similar
to the z/OS opcode NR, AND Registers.