Newbie question on Indices vs. Subscripts

I’ve been looking at table indices versus subscripts and can’t help wondering if the better performance of indices is something that might have been a real concern years ago but would be less so today considering improved code optimization by the compiler, and (perhaps) especially so if the subscript is typed as BINARY. For those of you working in the real world are indices still an important technique if you’re just going through a table sequentially?

Related to that, I know that table SEARCHes rely on the use of an index associated with the table, but what if I want to know the subscript of the row that satisfied the test? I guess I could include the row subscript as an actual data element in the structure that defines the row but that seems kinda clunky. Is there perhaps a general way to convert between indices and subscripts?

Hi alterkacker

AFAIK for the IBM compiler, the difference is, that when using indices, the actual position in the table is calculated when the value of the index is set.
Versus using a variable for index, the position is first calculated when the value is needed.
I have not looked through the generated assembly code to confirm this.

Also be aware, that if you are using an index from one table, as position in another table, your positions in the other table will most likely be wrong. As the positions are calculated for the first table.

Regards,
Rune

Indices can buy some small increase in speed, but increase the risk of error. I usually stayed with subscripts, which are more flexible and simpler to code.

John

Indices are required, of course, by both SEARCH and SEARCH ALL (the COBOL binary search for a sorted table). They are far more efficient than subscripts even if subscripts are defined as BINARY SYNC. They represent a displacement into the table so that the first element in the table is at index value 0. They can only be used on the table level where they are defined (given a name with INDEXED BY). You can still use the PERFORM VARYING statement with them the same as with a subscript. The only minor inconvenience is that you have to manipulate the index with the SET verb rather than the arithmetic verbs and move statement. Indices are especially necessary for good coding when you are using variable length tables and the number of elements goes into the thousands or more. You can still DISPLAY an index value by setting a subscript to the index and then displaying the subscript. The system will calculate the element number for the subscript given the index value.

1 Like

An index is fast as it is the actual address in memory of the table entry. When an index is set up by 1, the displacement of the entry is added to the index. This is done internally. When using subscripts, the relative occurrence is used. Thus, to find an entry in the table, the subscript has to be converted to a displacement. The most efficient subscripts are binary (S9(4) comp sync). Therefore, the machines has to add 1 to the subscript and then convert it to a displacement (two operations). That makes indexing faster and more efficient. However, in today’s world, MIPS are cheap and labor expensive. If you ponder this for more than a day, you will probably burn more cash in labor than for all the years of processing that lie ahead for the code.

Thanks everyone! Yep, I’ve decided to stop obsessing about it (thank you thesharpes!) and just accept the fact that SEARCHes use indices, not subscripts. And G_Decker, I didn’t know about using the SET statement for that purpose - thank you.

I must admit that I’m still surprised the COBOL Compiler isn’t smarter about optimizing access via subscripts. If I’m feeling really motivated (or masochistic) I’ll look at the assembler generated for the two different coding patterns.

Do note that when you’re really motivated you’ll need to use OPT(2) to get the best code for either indexes or subscripts. OPT(0) is intended to save compilation CPU when testing, rather than execution CPU.