COBOL Efficient Coding Techniques Part - 2.

Data Types : Using the proper data types is also an important factor in determining the performance characteristics of an application. Some of these are discussed below.

• BINARY (COMP or COMP-4)
  

When using binary (COMP) data items, the use of the SYNCHRONIZED clause specifies that the binary data items will be properly aligned on halfword, fullword, or doubleword boundaries. 

This may enhance the performance of certain operations on some machines. Additionally, using signed data items with eight or fewer digits produces the best code for binary items. The following shows the general performance considerations (from most efficient to least efficient) for the number of digits of precision for signed binary data items (using PICTURE S9(n) COMP) using TRUNC(OPT):

n is from 1 to 8 for n

from 1 to 4, arithmetic is done in halfword instructions where possible for n 

from 5 to 8, arithmetic is done in fullword instructions where possible 

n is from 10 to 17 

arithmetic is done in doubleword format 

n is 9 

fullword values are converted to doubleword format and then doubleword arithmetic is used (this is SLOWER than any of the above) 

n is 18 

doubleword values are converted to a higher precision format and then arithmetic is done using this higher precision (this is the SLOWEST of all for binary data items)

• COMP-5 : Binary COMP-5 data items are similar to the above BINARY (COMP and COMP-4) data items with the exception that they always behave as if the TRUNC(BIN) compiler option were in effect for them. Hence, the performance recommendations for BINARY (COMP or COMP-4) data items also apply for COMP-5 data items.
  

Performance considerations for COMP-5:  

 using 1 to 4 digits is the fastest  

 using 5 to 9 digits is 35% slower than using 1 to 4 digits.  

 using 10 to 18 digits is 2200% slower than using 1 to 4 digits.

• Data Conversions : Conversion to a common format is necessary for certain types of numeric operations when mixed data types are involved in the computation. This results in additional processing time and storage for these conversions. In order to minimize this overhead, it is recommended that the guidelines discussed below be followed.
  

• DISPLAY : Avoid using USAGE DISPLAY data items for computations (especially in areas that are heavily used for computations). When a USAGE DISPLAY data item is used, additional overhead is required to convert the data item to the proper type both before and after the computation. In some cases, this conversion is done by a call to a library routine, which can be expensive compared to using the proper data type that does not require any conversion.
  

Performance considerations for DISPLAY:  

using 1 to 15 digits (with an odd number of digits) is the fastest

 using 2 to 16 digits (with an even number of digits) is 16% slower than using 1 to 15 digits (with an odd | number of digits)  

using 17 to 18 digits is 60-70% slower than using 1 to 15 digits (with an odd number of digits)

• PACKED-DECIMAL (COMP-3) : When using PACKED-DECIMAL (COMP-3) data items in computations, use 15 or fewer digits in the PICTURE specification to avoid the use of library routines for multiplication and division. A call to the library routine is very expensive when compared to doing the calculation in-line. Additionally, using a signed data item with an odd number of digits produces more efficient code since this uses an integral multiple of bytes in storage for the data item.

Performance considerations for PACKED-DECIMAL:  

using an odd number of digits is 5% to 20% faster than using an even number of digits  

using the 16 to 18 digits is up to 140% slower than using 1 to 15 digits

• Fixed-Point vs Floating-Point : Plan the use of fixed-point and floating-point data types. You can enhance the performance of an application by carefully determining when to use fixed-point and floating-point data. When conversions are necessary, binary (COMP) and packed decimal (COMP-3) data with nine or fewer digits require the least amount of overhead when being converted to or from floating-point (COMP-1 or COMP-2) data. Also, when using fixed-point exponentiations with large exponents, the calculation can be done more efficiently by using operands that force the exponentiation to be evaluated in floating-point.
  

An example of forcing the exponentiation to be evaluated in floating-point is as follows:
 

 01   A              PIC S9(6)V9(12)         COMP-3 VALUE 0.
 01   B              PIC S9V9(12)             COMP-3 VALUE 1.234567891.
 01   C              PIC S9(10)                 COMP-3 VALUE -99999.

 COMPUTE A = (1 + B) ** C. (original)
 COMPUTE A = (1.0E0 + B) ** C. (forced to floating-point)
 

The above example was forced to floating-point by changing the fixed-point constant value 1 to a floating point constant value 1.0E0.

Performance considerations for fixed-point vs floating-point: forcing an exponentiation to be done in floating-point can be up to 98% faster than doing it in fixed- point

• Indexes vs Subscripts : Using indexes to address a table is more efficient than using subscripts since the index already contains the displacement from the start of the table and does not have to be calculated at run time. Subscripts, on the other hand, contain an occurrence number that must be converted to a displacement value at run time before it can be used. When using subscripts to address a table, use a binary (COMP) signed data item with eight or fewer digits (for example, using PICTURE S9(8) COMP for the data item). This will allow fullword arithmetic to be used during the calculations. Additionally, in some cases, using four or fewer digits for the data item may also offer some added reduction in CPU time since halfword arithmetic can be used.
  

Performance considerations for indexes vs subscripts (PIC S9(8)):  

using binary data items (COMP) to address a table is 30% slower than using indexes  

using packed decimal data items (COMP-3) to address a table is 300% slower than using indexes

using DISPLAY data items to address a table is 450% slower than using indexes

• OCCURS DEPENDING ON : When using OCCURS DEPENDING ON (ODO) data items, ensure that the ODO objects are binary (COMP) to avoid unnecessary conversions each time the variable-length items are referenced. Some performance degradation is expected when using ODO data items since special code must be executed every time a variable-length data item is referenced. This code determines the current size of the item every time the item is referenced. It also determines the location of variably-located data items. Because this special code is outof- line, it may inhibit some optimizations. Furthermore, code to manipulate variable-length data items is substantially less efficient than that for fixed-length data items. For example, the code to compare or move a variable-length data item may involve calling a library routine and is significantly slower than the equivalent code for fixed-length data items. If you do use variable-length data items, copying them into fixed-length data items prior to a period of high-frequency use can reduce some of this overhead.
  

Performance considerations for fixed-length vs variable-length tables:  

using variable-length tables is 5% slower then using a fixed-length table  

using a variable-length table that references the first complex ODO element is 7% slower then using a fixed-length table  

using a variable-length table that references a complex ODO element other than the first is 140% slower then using a fixed-length table

Created with Artisteer