Handling tables efficiently
You can use several techniques to improve the efficiency of table-handling operations, and to influence the optimizer. The return for your efforts can be significant, particularly when table-handling operations are a major part of an application.
About this task
The following two guidelines affect your choice of how to refer to table elements:
- Use indexing rather than subscripting.
Although the compiler can eliminate duplicate indexes and subscripts, the original reference to a table element is more efficient with indexes (even if the subscripts were
BINARY
). The value of an index has the element size factored into it, whereas the value of a subscript must be multiplied by the element size when the subscript is used. The index already contains the displacement from the start of the table, and this value does not have to be calculated at run time. However, subscripting might be easier to understand and maintain. - Use relative
indexing.
Relative index references (that is, references in which an unsigned numeric literal is added to or subtracted from the index-name) are executed at least as fast as direct index references, and sometimes faster. There is no merit in keeping alternative indexes with the offset factored in.
Whether you use indexes or subscripts, the following coding guidelines can help you get better performance:
- Put constant and duplicate indexes or subscripts
on the left.
You can reduce or eliminate runtime computations this way. Even when all the indexes or subscripts are variable, try to use your tables so that the rightmost subscript varies most often for references that occur close to each other in the program. This practice also improves the pattern of storage references and also paging. If all the indexes or subscripts are duplicates, then the entire index or subscript computation is a common subexpression.
- Specify the element length so that it matches that of related
tables.
When you index or subscript tables, it is most efficient if all the tables have the same element length. That way, the stride for the last dimension of the tables is the same, and the optimizer can reuse the rightmost index or subscript computed for one table. If both the element lengths and the number of occurrences in each dimension are equal, then the strides for dimensions other than the last are also equal, resulting in greater commonality between their subscript computations. The optimizer can then reuse indexes or subscripts other than the rightmost.
- Avoid errors in references by
coding index and subscript checks
into your program.
If you need to validate indexes and subscripts, it might be faster to code your own checks than to use the
SSRANGE
compiler option.
You can also improve the efficiency of tables by using these guidelines:
- Use
binary data items for all subscripts.
When you use subscripts to address a table, use a
BINARY
signed data item with eight or fewer digits. In some cases, using four or fewer digits for the data item might also improve processing time. - Use
binary data items for variable-length table items.
For tables with variable-length items, you can improve the code for
OCCURS DEPENDING ON
(ODO). To avoid unnecessary conversions each time the variable-length items are referenced, specifyBINARY
forOCCURS . . . DEPENDING ON
objects. - Use fixed-length
data items whenever possible.
Copying variable-length data items into a fixed-length data item before a period of high-frequency use can reduce some of the overhead associated with using variable-length data items.
- Organize tables according to the type of search
method used.
If the table is searched sequentially, put the data values most likely to satisfy the search criteria at the beginning of the table. If the table is searched using a binary search algorithm, put the data values in the table sorted alphabetically on the search key field.