Posted: Sat Nov 24, 2007 2:20 pm Post subject: using Index other than subscript
while handling Arrays/tables in cobol, we can either use subscript or Index. more over we can do Search or search ALL(which needs index) using subscript too using perform verbs. but will you please tell me that something for which we have to use Index and cannot be done using subscript. ( not relating to any performance issues)
Venkatreddy point that out about the index for SEARCH ALL.
Define "MUCH", this is computing, after all. Only with single bytes? Can you show that?
I have a 9,999 entry table (which is what I assume you mean by "array"). Each entry in the table is 30 bytes long, accessed as three separate fields. Which do you determine would be "more efficient" to access this, an index or a subscript defined as COMP PIC 9(4)/S9(4)?
But still, how "MUCH" is "MUCH"? The quote you give, shorn of its specific context, just says "more efficient". It's context, which I know without having to look, is of PIC S9( binary, plus packed-decimal, plus DISPLAY.
What about the "single bytes"?
And the other specific question? I was wondering about your answer, Chuck - how "much"? Now we can access the entire table with a binary halfword. Three instructions for the subscript, two for the index, but the subscript is halfword, the index always fullword. You still going for "MUCH" faster?
Joined: 18 Apr 2010 Posts: 18 Location: St. Cloud, Minnesota, USA
Posted: Tue Jan 01, 2013 1:13 pm Post subject:
from the Enterprise COBOL performance manual i quoted above. One of the factors which affect these results is how many times subscripted / indexed items are referenced in the code. The more references, the greater the savings. Also muliple dimensioned arrays will also show a greater savings.
ps.. the rationale behind the array with entries which are only 1 byte long is that when the compiler is calculating the displacement, it doesn't have to multiply the subscript times the entry length so effectively it functions very similar to an index.
Indexes vs Subscripts
Using indexes to address a table is more efficient than using subscripts since the index already contains the
displacement from the start of the table and does not have to be calculated at run time. Indexes are defined
using the INDEXED BY phrase of the OCCURS clause for the data item. Subscripts, on the other hand,
contain an occurrence number that must be converted to a displacement value at run time before it can be
used. When using subscripts to address a table, use a binary (COMP) signed data item with eight or fewer
digits (for example, using PICTURE S9( COMP for the data item). This will allow fullword arithmetic to
be used during the calculations. Additionally, in some cases, using four or fewer digits for the data item may
also offer some added reduction in CPU time since halfword arithmetic can be used.
Performance considerations for indexes vs subscripts (PIC S9():
Using binary data items (COMP) to address a table is 40% slower than using indexes
Using packed decimal data items (COMP-3) to address a table is 220% slower than using indexes
Using DISPLAY data items to address a table is 300% slower than using indexes _________________ Chuck Haatvedt
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
Joined: 28 Apr 2009 Posts: 11 Location: Missouri USA
Posted: Fri Jan 22, 2016 9:54 pm Post subject:
Let me add to the "much" answer.
If you have a table that is indexed and the key to the table is in sequence you will be able to do a SEARCH ALL on the table. Assume, for that the table contains 1,000,000 entries. (yes, that might unreasonable, but go with it for a minute) Doing a SEARCH ALL on the table will only look at 20 entries to determine if what you're looking up in the table is there or not. You've only coded one verb (the SEARCH).
If you're using subscripting you'll have to code your own routine to do the same binary search, with the possibility of making coding mistakes.
If you just do a sequential search on the same table you'll have to do an average of 500,000 comparisons to find, or not find, what you're looking for. Let's see 20 vs 500,000??? I'd say that would be MUCH faster. _________________ David Earhart
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum