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?
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.
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.
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.
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.
A questão não esta necessariamente no COMPILADOR ser ou não ser mais inteligente para tratar um SUBSCRITOR.
Quando utilizamos um índice premissas relacionadas à tabela já estão previamente estabelecidas, como tamanho da ocorrência, por exemplo.
Quando utilizamos Subscritores tais premissas não existem e são identificadas em tempo de execução, razão pela qual, um mesmo subscritor pode ser utilizado em várias tabelas representando informações de uma mesmo elemento identificado inicialmente através do posicionamento do Subscritor desejado.
Posso com toda a certeza afirmar que se a Tabela tiver 4 ou mais níveis, obrigatoriamente, deverá ser utilizado um subscritor, e todo o manuseio da mesma deverá ser feito por algoritmo desenvolvido e atualizado pelo programador.
Lembro-me que certa vez tive a necessidade de desenvolver, em uma Aplicação CSP, uma Tabela quadrimencional com ocorrências dinâmica que tinha a necessidade de espelhar a quantidade de elementos em CADA tabelas utilizadas.
Logo, u utilização de Índices x Subscritores esta relacionada a complexidade de sua necessidade, principalmente, por que o SEARCH ALL tem incluso um algoritmo de maximização de pesquisa.
A questão não esta necessariamente na obrigatoriedade do COMPILADOR ser ou não ser mais inteligente para tratar um ÍNDICE, ou um “Subscritor”.
Quando utilizamos um índice premissas relacionadas à tabela já estão disponíveis, como tamanho da ocorrência, por exemplo.
Quando utilizamos “Subscritores” tais premissas não existem e são identificadas em tempo de execução, razão pela qual, um mesmo “Subscritor” pode ser utilizado em várias tabelas representativas de um mesmo elemento identificado através do posicionamento do “Subscritor” desejado em uma tabela referência.
Posso com toda a certeza afirmar que se a Tabela tiver 4 ou mais níveis, obrigatoriamente, deve ser usado um “Subscritor”, e todo o manuseio da mesma deve ser feito por algoritmo desenvolvido e atualizado pelo programador.
Lembro-me que certa vez havia a necessidade de desenvolver, uma Aplicação CSP, com uma Tabela com quatro dimensões e com quantidade de ocorrências dinâmica, uma vez que, tinha a necessidade de espelhar a quantidade de elementos existentes em CADA tabela origem.
Logo, a utilização de Índices x “Subscritores” esta relacionada a complexidade de sua necessidade, principalmente, por que o “SEARCH_ALL” tem incluso um algoritmo (pesquisa binária) de maximização de pesquisa.