The appropriate program design is another important factor in determining the performance character-istics of an application. If an inefficient design is used, then you are limited in the amount of performance
tuning you can do to the application.
The biggest performance improvement you can make is to use an efficient design. After the design is determined, then you can look at other things such as efficient algo-rithms, data structures and data types, and coding style. Some of these are discussed below.
The biggest performance improvement you can make is to use an efficient design. After the design is determined, then you can look at other things such as efficient algo-rithms, data structures and data types, and coding style. Some of these are discussed below.
- Algorithms : Examine the underlying algorithms that have been selected before looking at the COBOL specifics. Improving the algorithms usually has a much greater impact on the performance than does improving the detailed implementation of the algorithm. As an example, consider two search algorithms: a sequential search and a binary search. Clearly, both of them will produce the same results and may, in fact, have almost the same performance for small tables. However, as the table size increases, the binary search will be much faster than the sequential search. As in this case of the two searches, you may have to do some additional coding to maintain a sorted table for the binary search, but the additional effort spent here is more than saved during the execution of the program.
- Data Structures and Data Types : After deciding on the algorithm, look at the data structures and data types. Ensure that both are appropriate for the selected algorithm. The algorithm may in general be a fast one, but if the wrong data structures or types are used, the performance can degrade significantly. As an example, consider two PERFORM VARYING loops, one using a USAGE DISPLAY data item for the loop variable and the other using a COMPUTATIONAL data item. In the case of DISPLAY data item, data conversion must be done for each iteration of the loop, whereas in the COMPUTATIONAL data item, binary fullword arithmetic can be used. Once again, they will both produce the same results, but the loop using the COMPUTATIONAL data item will be much faster than the loop using the DISPLAY data item.
Performance considerations for loop control variables (PIC S9(8)):
using packed decimal (COMP-3) is 280% slower than using binary (COMP)
using DISPLAY is 575% slower than using binary (COMP)
- Coding Style : Examine the coding style. Ensure that the program is well structured, utilizing the structured coding constructs that are available with IBM Enterprise COBOL. Avoid using the GO TO statement (in particular, the altered GO TO statement) and avoid using PERFORMed procedures that involve irregular control flow (for example, a PERFORMed procedure that cannot reach the end of the procedure). The optimizer can optimize the code better and over larger blocks of code if the programs are well structured and don't have a "spaghetti-like" control flow. Additionally, the programs will be easier to maintain because of the structured logic flow.
- Factoring Expressions : Factor expressions where possible, especially in loops. The optimizer does not do the factoring for you. For evaluating arithmetic expressions, the compiler is bound by the left-to-right evaluation rules for COBOL. In order for the optimizer to recognize constant computations (that can be done at compile time) or duplicate computations (common subexpressions), move all constants and duplicate expressions to the left end of the expression or group them in parentheses.
- Symbolic Constants : If you want the optimizer to recognize a data item as a constant throughout the program, initialize it with a VALUE clause and don't modify it anywhere in the program (if a data item is passed BY REFERENCE to a subprogram, the optimizer considers it to be modified not only at this CALL statement, but also at all CALL statements).
- Subscript Checking : When using tables, evaluate the need to verify subscripts. Using the SSRANGE option to catch the errors causes the compiler to generate special code at each subscript reference to determine if the subscript is out of bounds. However, if subscripts need to be checked in only a few places in the application to ensure that they are valid, then coding your own checks can improve the performance when compared to using the SSRANGE compiler option.
- Subscript Usage : Additionally, try to use the tables so that the rightmost subscript varies the most often for references that occur close to each other in the program. The optimizer can then eliminate some of the subscript calculations because of common subexpression optimization.
Performance considerations for table reference patterns (PIC S9(8)):
when referencing tables sequentially, having the leftmost subscript vary the most often can be 50%
slower than having the rightmost subscript vary the most often
- Searching : When using the SEARCH statement, place the most often used data near the beginning of the table for more efficient sequential searching. For better performance, especially when searching large tables, sort the data in the table and use the SEARCH ALL statement. This results in a binary search on the table.
Performance considerations for search example:
using a binary search (SEARCH ALL) to search a 100-element table was 6% faster than using a sequential search (SEARCH)
using a binary search (SEARCH ALL) to search a 1000-element table was 83% faster than using a
sequential search (SEARCH).
No comments:
Post a Comment