[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

HP COBOL
User Manual


Previous Contents Index

15.4 Other Ways to Improve the Performance of Operations on Numeric Data

In addition to using COMP data items whenever possible for arithmetic operations in programs, there are other ways to improve performance through the choice of numeric data types, as discussed in this section.

15.4.1 Mixing Scale Factors and Data Types

Scaling is the process of aligning decimal points for numeric data items. Where possible, avoid mixing different scale-factors and data types in arithmetic operations.

In general, type conversions can be minimized by using operands of the same usage. Scaling operations can be minimized by using compatible scale factors according to the operation. For example, for add and subtract, all operands should have the same number of fractional digits; for multiply, the number of fractional digits in the result should be the same as the sum of the number of fractional digits in the other two operands.

15.4.2 Limiting Significant Digits

In general, the fewer significant digits in an item, the better the performance (except as described in Section 15.4.1). For example, for a numeric data item to contain a number from 1 to 999, declare it as PIC 9(3), not PIC 9(10). This will also save storage.

15.4.3 Reducing the Compexity of Arithmetic Expressions

When the compiler evaluates an arithmetic expression, it must create intermediate data items to store the cumulative results of the successive arithmetic operations in the expression. Such intermediate data items have PICTUREs large enough to hold the largest and smallest possible intermediate resulting values for the particular arithmetic operation and the data items upon which it operates. In general, the more complex the arithmetic expression, the larger each successive intermediate data item's PICTURE grows. In particular, if a divide or exponentiation operation is not the last or only arithmetic operation in the expression, the corresponding intermediate data item and subsequent intermediate data items will have very large PICTUREs, which will adversely affect performance.

If you can break complex arithmetic expressions into two or more simpler expressions, performance can be greatly improved. Try to break expressions to make any divide or exponentiation operation the last operation in the subexpression. Store the results of each subexpression in data items you declare, and ensure that such data items have PICTUREs just sufficient to hold the expected partial results.

15.4.4 Selection of Data Types (OpenVMS)

The Alpha architecture provides a full set of arithmetic operations for G-FLOAT. When your program operates upon G-FLOAT data items, the arithmetic operations are carried out at maximum native speed and with full precision. When D-FLOAT data types are encountered in your program source the HP COBOL compiler must perform a conversion to G-FLOAT. Similarly, data returned from an arithmetic

While these operations are actually transparent to you, there is a cost in both performance and accuracy, as some data can be lost in the two conversions.

HP COBOL supports different floating-point data types on each platform it supports, as summarized below:

Platform Supported Floating-Point Data Types
OpenVMS Alpha F-FLOAT, D-FLOAT, G-FLOAT, S-FLOAT, T-FLOAT
OpenVMS I64 F-FLOAT, D-FLOAT, G-FLOAT, S-FLOAT, T-FLOAT
OpenVMS VAX F-FLOAT, D-FLOAT
Tru64 UNIX S-FLOAT, T-FLOAT

The OpenVMS VAX floating-point implementation on OpenVMS Alpha is not totally compatible with the VAX floating-point implementation on VAX. Similarly, the OpenVMS VAX floating-point implementation on OpenVMS I64 is not totally compatible with the VAX floating-point implementations on either VAX or Alpha.

In general, you should use the floating-point data types that are appropriate to your particular applications. In some cases, you have data in files based on a particular floating-point data type. In other cases, you are sharing floating-point data with modules written in other languages and the choice of which floating-point data type to use is dictated by the application's call interface.

If you are planning to use floating-point data where you are not already constrained by the application, it may make sense for you to use the specified defaults for each platform. Since all languages, including COBOL, have different defaults on different platforms, take this into account when deploying applications across multiple platforms.

For more information on floating-point arithmetic on the OpenVMS I64 operating system, see the whitepaper at:


http://www.hp.com/products1/evolution/alpha_retaintrust/download/i64-floating-pt-wp.pdf

15.5 Choices in Procedure Division Statements

Some Procedure Division statements make better use of the HP COBOL compiler than others. This section describes these statements and shows how to use them.

15.5.1 Using Indexing Instead of Subscripting

Using index names for table handling is generally more efficient than using PACKED-DECIMAL or numeric DISPLAY subscripts, since the compiler declares index names as binary data items. Subscript data items described in the Working-Storage Section as binary items are as efficient as index items. Indexing also provides more flexibility in table-handling operations, since it allows you to use the SEARCH statement for sequential and binary searches.

The following two examples are equally efficient:

Example 1


WORKING-STORAGE SECTION.
01  TABLE-SIZE.
    03  FILLER                      PIC X(300).
01  THE-TABLE REDEFINES TABLE-SIZE.
    03  TABLE-ENTRY OCCURS 30 TIMES PIC X(10).
01  SUB1          PIC S9(5) BINARY VALUE ZEROES.

Example 2


WORKING-STORAGE SECTION.
01  TABLE-SIZE.
    03  FILLER                      PIC X(300).
01  THE-TABLE REDEFINES TABLE-SIZE.
    03  TABLE-ENTRY OCCURS 30 TIMES PIC X(10)
                    INDEXED BY IND-1.

15.5.2 Using SEARCH ALL Instead of SEARCH

When performing table look-up operations, SEARCH ALL, a binary search operation, is usually faster than SEARCH, a sequential search operation. However, SEARCH ALL requires the table to be in ascending or descending order by search key, while SEARCH imposes no restrictions on table organization. Also, with SEARCH ALL there should be unique key values in the table. Before using SEARCH ALL, you must pre-sort the table. If the table is not sorted, SEARCH ALL often gives incorrect results.

The SORT statement (Format 2, which is an HP extension) can be used to sort an entire table. This is particularly useful in connection with SEARCH ALL. Refer to the SORT statement description in the Procedure Division chapter of the HP COBOL Reference Manual for the syntax and examples.

A binary search (SEARCH ALL) determines a table's size, finds the median table entry, and searches the table in sections, by using compare processes. A sequential search (SEARCH) manipulates the contents of an index to search the table sequentially. Section 4.3.8 contains examples of binary and sequential table-handling operations.

SEARCH ALL is supported for the EBCDIC as well as the ASCII collating sequence, on both VAX and Alpha.


Previous Next Contents Index