| Previous | Contents | Index |
Proper alignment of numeric data items within record structures can
make run-time performance significantly faster. See Chapter 16 for
information on data alignment specified on the compiler command line,
and information on compiler directives that specify alignment. Refer to
the Compaq COBOL Reference Manual for information on the SYNCHRONIZED clause, which is
also used to specify alignment. <>
15.3 Using COMP Data Items for Speed
Large, compute-intensive applications can often run faster if arithmetic data items are USAGE COMP.3 As you write COBOL code, maximize your use of COMP for arithmetic operands. COMP data items typically run faster for arithmetic operations than PACKED-DECIMAL (COMP-3) or DISPLAY data items. In general, the following guidelines hold true:
For existing COBOL programs, you should consider converting numeric data items to COMP if an application is compute-bound and time-critical and you would like to improve execution speed. Some factors in the decision whether to convert are discussed in this section.
Precision Not Reduced by Conversion to COMP
The data types usually employed for COBOL data items are summarized below:
| Usage | Data Type |
|---|---|
|
COMP, BINARY,
COMP-5, COMP-X |
Binary |
| COMP-1 |
F-Float (compiled with /FLOAT=D_FLOAT
or /FLOAT=G_FLOAT) |
| S-Float (compiled with /FLOAT=IEEE_FLOAT) | |
| COMP-2 | D-Float (compiled with /FLOAT=D_FLOAT) |
| G-Float (compiled with /FLOAT=G_FLOAT) | |
| T-Float (compiled with /FLOAT=IEEE_FLOAT) | |
|
COMP-3,
PACKED-DECIMAL |
Packed-decimal |
| DISPLAY | Text or decimal |
On Tru64 UNIX systems, the F_FLOAT, D_FLOAT and G_FLOAT data types are not supported. <>
Operations on COMP-1 and COMP-2 data items are fast. However, it is not recommended that you convert data items to COMP-1 or COMP-2, because you could lose precision. Floating-point numbers are approximations using a scientific notation relative to powers of two. A COMP-1 operand gives approximately 7 decimal digits of precision, a COMP-2 approximately 15; either often represents a value less precisely than the other data types, which are fixed point.
The semantics of COMP (BINARY, COMP-5, COMP-X), COMP-3 (PACKED-DECIMAL), and DISPLAY operands are the same: each can be scaled (except for COMP-5 and COMP-X) and signed, and can hold up to 18 decimal digits. Therefore, converting existing programs from COMP-3 or DISPLAY to COMP will yield results that are no less accurate or precise. The only effect on operands is the method of storage; and the primary effect on operations is improved performance.
Because changing the data type changes the way data is stored, you may not be able to change the data type of items that participate in a REDEFINES or that are elements of file record structures.
Tools That Can Help You Decide Whether to Convert a Program
Compaq does not recommend a massive conversion of all source programs to use COMP operands. Most existing COBOL programs perform very well, and conversions of old programs can be expensive. The following tools can help you decide which programs would run significantly faster if converted, and to discover program interdependencies:
On OpenVMS, the Performance and Coverage Analyzer (PCA) can target specific areas of programs that require large amounts of CPU time. If 80 percent of the processing time is used by 20 percent of the COBOL routines, you may benefit from converting only these routines to use COMP.
The Source Code Analyzer (SCA) can help discover program interdependencies as you contemplate changes. For example, if it is proposed that an item declared COMP-3 be changed, SCA can quickly and easily find all the references to that item.
If SCA is used in conjunction with the Language-Sensitive Editor (LSE), LSE can bring up buffers in your editing session with each of the references.
The Common Data Dictionary can store data definitions and dependency information, which can then be maintained from one centralized location. <>
On Tru64 UNIX, these performance analysis tools can be used to identify programs ( prof ) or sections of programs ( pixie ) that require large amounts of CPU time. If 80 percent of the processing time is used by 20 percent of the COBOL routines, you may benefit from converting only these routines to use COMP. <>
3 Following are some reasons: COMP data items can be manipulated by direct and natural use of the Alpha instruction set. Manipulation of decimal types requires longer sequences of instructions, most of which are implemented as Compaq COBOL Run-Time Library routines. While floating point is also a natural Alpha data type, it does not support the full 18-digit precision allowed in COBOL. For more information, refer to the Compaq COBOL Reference Manual. |
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 Compaq COBOL compiler must perform a conversion to G-FLOAT. Similarly, data returned from an arithmetic operation must be converted from G-FLOAT to your declared data type.
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. Wherever you have the luxury of choice, Compaq suggests
you use G-FLOAT data types in your programs. <>
15.5 Choices in Procedure Division Statements
Some Procedure Division statements make better use of the
Compaq 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:
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.
|
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.
|
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 a Compaq 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 Compaq 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.
15.5.3 Selecting Hypersort or SORT-32 for Sorting Tasks
Hypersort is a high-performance sorting tool. COBOL has Hypersort on both Alpha platforms: OpenVMS and Tru64 UNIX.
On Tru64 UNIX, Hypersort is the only method. <>
On OpenVMS Alpha, a different sorting method, SORT-32, is the default, but you can choose Hypersort instead for both sorting within COBOL and sorting at the DCL level. Refer to the DCL online help (type $HELP SORT) for details on the differences between the two sorting methods and instructions for switching between methods. <>
On OpenVMS VAX, only SORT-32 is available. <>
15.5.4 Minimizing USE Procedures with LINKAGE SECTION References
Compaq COBOL can perform certain optimizations if a program unit does not contain USE procedures that reference LINKAGE SECTION items. Note that USE procedures implicitly reference the following variables for any files associated with the USE procedures:
FILE STATUS
DEPENDING ON
RELATIVE KEY
LINAGE-COUNTER
Record buffer
If you need to reference LINKAGE SECTION items in a USE procedure, try
to limit the size of the program unit containing that USE procedure.
Compaq COBOL will be able to perform more aggressive optimizations on
all the other program units that do not contain the LINKAGE SECTION
references in any USE procedures.
15.6 I/O Operations
Compaq COBOL provides methods of controlling actions taken by the I/O system during I/O operations. You have the choice of accepting the defaults the I/O system provides or using these optional methods to make your program more efficient.
The Compaq COBOL language elements that can specify alternatives to the I/O system defaults are as follows:
On OpenVMS, for additional information on the RMS terms and concepts
included in this section, refer to the OpenVMS Record Management Utilities Reference Manual and the
OpenVMS Record Management Services Reference Manual.
15.6.1 Using the APPLY Clause
On OpenVMS, the APPLY clause in the I-O-CONTROL paragraph of the Environment Division provides phrases that you can use to improve I/O processing. <>
On Tru64 UNIX systems, many elements of the I-O-CONTROL paragraph are for documentation only (accepted and ignored by the compiler), including the phrases described in this section. <>
For complete information on the APPLY clause and its phrases, refer to
the I-O-CONTROL section of the Environment Division chapter in the
Compaq COBOL Reference Manual.
15.6.1.1 Using the PREALLOCATION Phrase of the APPLY Clause (OpenVMS)
By default, the system does not preallocate disk blocks. As a result, files can require multiple extensions of disk blocks. Although file extension is transparent to your program, it can reduce performance. To avoid a degradation in performance, use the APPLY PREALLOCATION clause to preallocate disk blocks.
Specifying APPLY PREALLOCATION preallocates noncontiguous disk blocks. When you specify the CONTIGUOUS-BEST-TRY phrase, the I/O system makes up to three attempts to allocate as many contiguous disk blocks as it can; it then preallocates remaining blocks noncontiguously. The CONTIGUOUS-BEST-TRY phrase minimizes disk space fragmentation and gives better system throughput than CONTIGUOUS.
The APPLY CONTIGUOUS (physically adjacent) clause makes one attempt at contiguous preallocation; if it fails, the OPEN operation fails. Use APPLY CONTIGUOUS if you require contiguous physical space on disk.
Contiguous files can reduce or eliminate window turning. When you access a file, the file system maps virtual block numbers to logical block numbers. This map is a window to the file. It contains one pointer for each file extent. The file system cannot map a large noncontiguous file: the file system may have to turn the window to access records in another extent. However, a contiguous file is one extent. It needs one map pointer only, and window turning does not take place after you open the file.
The following statements create a file (after OPEN/WRITE) and preallocate 150 contiguous blocks:
ENVIRONMENT DIVISION.
FILE-CONTROL.
SELECT A-FILE ASSIGN TO "MYFILE".
.
.
.
I-0-CONTROL.
APPLY CONTIGUOUS PREALLOCATION 150 ON A-FILE.
.
.
.
|
The format of APPLY EXTENSION is as follows:
APPLY EXTENSION extend-amt ON { file-name } ...
The APPLY EXTENSION clause is another way to reduce I/O allocation and extension time. Adding records to a file whose current extent is full causes the file system to extend the file by one disk cluster. (A disk cluster is a set of contiguous blocks; its size is determined when you initialize the volume with the DCL INITIALIZE command or when the volume is mounted with the DCL MOUNT qualifier: /EXTENSION=n.)
You can override the default extension by specifying the number of
blocks in the APPLY EXTENSION clause. The APPLY EXTENSION integer
becomes a file attribute stored with the file.
15.6.1.3 Using the DEFERRED-WRITE Phrase of the APPLY Clause (OpenVMS)
The format of APPLY DEFERRED-WRITE is as follows:
APPLY DEFERRED-WRITE ON { file-name } ...
Each WRITE or REWRITE statement can cause an I/O operation. The APPLY
DEFERRED-WRITE clause permits writes to a file only when the buffer is
full. Reducing the number of WRITE operations reduces file access time.
However, the APPLY DEFERRED-WRITE clause can affect file integrity:
records in the I/O buffer are not written to the file if the system
crashes or the program aborts. DEFERRED-WRITE is very useful on
write-shared files.
15.6.1.4 Using the FILL-SIZE ON Phrase of the APPLY Clause (OpenVMS)
The format of APPLY FILL-SIZE is as follows:
APPLY FILL-SIZE ON { file-name } ...
Use the APPLY FILL-SIZE clause to populate (load) the file and force the Compaq COBOL compiler to write records into the bucket area not reserved by the fill number. Routine record insertion uses the fill space, thereby reducing bucket splitting and the resulting overhead.
Do not use the APPLY FILL-SIZE clause for routine record insertion; it
prohibits the use of bucket fill space and creates unnecessary buckets.
15.6.1.5 Using the WINDOW Phrase of the APPLY Clause (OpenVMS)
The format of APPLY WINDOW is as follows:
APPLY WINDOW ON { file-name } ...
Window size is the number of file mapping pointers stored in memory. A large window improves I/O because the system spends less time remapping the file.
When a disk is initialized, the default window size is set by
specifying the /WINDOW qualifier. You can override this qualifier with
the APPLY WINDOW clause. However, avoid specifying too large a window
size. Window size is part of the system's pool space, and a large
window size could affect system performance. <>
15.6.2 Using Multiple Buffers
Multibuffering can increase the speed of I/O operations by reducing the number of file accesses. When a program accesses a record already in the I/O buffer, the system moves the record to the current record area without executing an I/O operation.
You can specify multiple buffering by using the RESERVE clause in the SELECT statement of the Environment Division. The RESERVE clause specification overrides the system default. (The system default is usually set by means of the DCL SET RMS_DEFAULT command.) The following example reserves six areas for FILE-A:
SELECT FILE-A ASSIGN TO "FILE-A"
RESERVE 6 AREAS.
|
You can specify up to 127 areas in the RESERVE clause. In general,
specifying from 2 to 10 areas is best.
15.6.3 Sharing Record Areas
The compiler allocates unique storage space in the Data Division for each file's current record area. Transferring records between files requires an intermediate buffer area and adds to a program's processing requirements.
To reduce address space and processing overhead, files can share current record areas. Specify the SAME RECORD AREA clause in the I-O-CONTROL paragraph of the Environment Division. Records need not be the same size, nor must the maximum size of each current record area be the same.
Figure 15-1 shows the effect of current record area sharing in a program that reads records from one file and writes them to another. However, it also shows a drawback: current record area sharing is equivalent to implicit redefinition. The records do not exist separately. Therefore, if the program changes a record defined for the output file, the input file record is no longer available.
Figure 15-1 Sharing Record Areas
| Previous | Next | Contents | Index |