I have to use an cobol array with only 7 occurances.
Can anyone suggest what would be better -- To use subscript or to use index?
I know that index is faster than subscript but with such a low number of occurances would it matter??? Also I think using Index will increase overhead. Please suggest.
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
From the Enterprise COBOL Programming Guide manual:
Quote:
8.1.3 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.
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.
However, for a table of 7 occurrences, the true answer is: you've already wasted more time thinking about the question than could EVER be saved by the program, no matter if it runs hourly for the next 50 years.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
the idea of indexing/subscripting is to allow for loops, thus saving on repetitive code.
since any use of 'indexing' involves a compare (does this occurance fit)
and a if not, a 'bump' of the index and another compare.
true, you could be just adding or subtracting or plain extracting,
but you have a loop where the 'bump' of the 'index' is required.
with a table with only 7 occurances,
absolute indexing (literal number)
would only entail 7 compares without the bumping,
you would save the runtime requirement to calculate the address (subscript + 1, or set up/down index by n)
since the compiler would have calculated the address.
Perform varying index/subscript from 1 by 1 until
involves the run time calculation,
whereas
Code:
EVALUATE TRUE
WHEN ITEM(1) = COMPARE
.....
WHEN ITEM(2) = COMPARE
.....
WHEN ITEM(3) = COMPARE
.....
WHEN ITEM(4) = COMPARE
.....
WHEN ITEM(5) = COMPARE
.....
WHEN ITEM(6) = COMPARE
.....
WHEN ITEM(7) = COMPARE
.....
OTHERWISE
.....
END-EVALUATE
would actually run faster, because there is no address calculation.
that said,
as Robert indicated,
with 7 occurances, and todays processor speeds,
you are wasting time even talking about the difference between indexing vs subscripting.
Another philosophical discussion posed by someone who does not understand the subject.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Quote from Robert -
Quote:
However, for a table of 7 occurrences, the true answer is: you've already wasted more time thinking about the question than could EVER be saved by the program, no matter if it runs hourly for the next 50 years.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
I know that index is faster than subscript but with such a low number of occurances would it matter??? Also I think using Index will increase overhead. Please suggest.
Suggest you set up a few little test modules (one for each approach you want to measure) that do the same "loop"/evaluate/etc several million times and look at the resources required. If you only do 100 or so loops, the difference might not be a good representation of the resource usage - high volume is needed . . .
