IBM Mainframe Forum

Hi,

In a recent performance drive it was a suggested that usage of indexes was better than subscripts and would lead to performance improvement in a COBOL code.

EXISTING CODE:

01 H-VAR.
03 H-VAR1 PIC X(5) OCCURS 10.

If index is used in the above code will this lead to any significant performance improvement in COBOL?

Indexes are more efficient than subscripts since they represent an offset into the array directly rather than having to be converted from an occurrence number to an offset. Having said that, though, unless you are accessing the array tens (or hundreds) of millions of times in your code you will see no appreciable difference in performance between indexes and subscripts.

from the perspective of an employer, lets assume that you need a program written which makes very heavy use of array processing.

You have two programmers to choose between.

programmer A writes inefficient code using subscripts which cost $100,000.00 per year in operational cpu costs.

programmer B writes efficient code using subscripts which cost $30,000.00 per year in operational cpu costs.


Which programmer would you hire ?

Chuck Haatvedt

From my own perspective I always try to deliver a cost effective solution to my employer. As a person learns how to code efficiently, it doesn't take much additional effort to write efficient code.

Hello,

I'd hire the person who wrote code that worked 100% of the time and was easily maintainable.

I've not yet hired anyone because i believed they would write more efficient array-handling code.

A very small percent of application code is "array processing bound". . .

I saw this topic while trying to figure out the following results while doing some benchmarking for a client.

We are attempting to prove the IBM position that using indexes to access tables is the fastest, using subscripts of usage COMP is 30% slower, using subscripts of usage COMP-3 is 200% slower and using subscripts of usage DISPLAY is 450% slower (see IBM reference at end of post).

The table size is either 10000 or 50000 rows. There are 4 fields per row. The program loops through the following 1000 times: initialize table, load the entire table, unload the entire table to a report (dummied out, of course). The following results show the CPU seconds for each execution.

TABLE
SIZE DISPLAY COMP COMP-3 INDEXED

10000 2.80 2.31 2.79 2.28
50000 13.40 10.67 12.13 10.74

These results show that it really doesn't matter what usage you assign to the subscript, the biggest savings (COMP vs. DISPLAY) is only 25.6%. Also, indexes are basically the same as usage COMP. Can anyone explain these results?

IBM Enterprise COBOL Version 3 Release 1
Performance Tuning
January 16, 2002
R. J. Arellanes
IBM Corporation
Software Solutions
555 Bailey Avenue
San Jose, CA 95141

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. 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(8) 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(8)):
| using binary data items (COMP) to address a table is 30% slower than using indexes
| using packed decimal data items (COMP-3) to address a table is 300% slower than using indexes
| using DISPLAY data items to address a table is 450% slower than using indexes
| (COB PG: pp 59-61, 537-538)

Hello and welcome to the forum,

You would need to know exactly what IBM used to perform the data gathering. The best (and maybe only) place to get this information is from the people who ran and published the information.

Notice that the quoted material is 8 years old (probably more as it takes time to get everything ready for publication).

The timings IBM refers to are probably just the memory access, while you are measuring the entire program. This is much like comparing apples to elephants -- not even in the same kingdom, much less anything closer. If you really think you need to replicate IBM's results you would have to have (probably several weeks of) intensive discussions with IBM about their methodology, ensure you have tools to measure individual machine instructions (very expensive, I'm sure), and spend a few weeks developing the precise code needed for the testing -- just throwing together a program is probably the worst possible way to do this type of testing.

The bigger question, however, is why on earth would you think you need to replicate IBM's results? They've done the work, published it, and you can therefore take advantage of it without having to do it yourself. Doing so is an expensive, and probably futile, effort.

When doing an index vs subscript performance test, I use the the following to test relative performance.

In the examples below look at the "UNTIL" clause in the TEST009 program. When comparing an index to a numeric field, the compiler generates extra code to convert both to the same format. Remember than an INDEX is stored as a displacement so when comparing to a number the index has to be divided by the length of 1 entry of the array. Then it has to add 1 to that number. The logic to convert the index to a numeric value would distort the comparison.

Note that TEST009 uses an elementary USAGE INDEX field to eliminate this conversion every time thru the loop. Use the "LIST" compiler option and look at the generated ASSEMBLER code for the UNTIL clause.

a comparison which will show the difference is between TEST005 and TEST009 as they both use INDEXES. The only difference is the UNTIL clause.

Hi Guys,

I and my team member had a argument on subscript.I said " value of subscript can be zero"..When set to zero, cobol implicitly assumes it lowest value as one.Please let me know your thoughts whether I am correct or wrong???

Hello and welcome to the forum,

Suggest you run a little experiment on your system and if you see something that is confusing, post your doubt back here - someone will be able to clarify.

When set to zero, cobol implicitly assumes it lowest value as one

Please post which documentation has this. . .