View previous topic :: View next topic
|
Author |
Message |
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
Hi,
When a program has a huge array and it needs to be initialized constantly, it may affect the performance of the program.
I tried the following and the 3rd option seemed to be the best by far:
1)
Code: |
INITIALIZE WS-ARRAY
|
2)
Code: |
MOVE LOW-VALUE TO WS-ARRAY |
3)
Code: |
COMPUTE WS-USED-ARRAY-LENGTH = LENGTH OF WS-ARRAY-ITEM * WS-LAST-ARRAY-ITEM-NUMBER
MOVE LOW-VALUE TO WS-ARRAY(1:WS-USED-ARRAY-LENGTH) |
In the real test for option 3, I used a "multiply" instead of a "compute" and saved the length of the array item in a ws variable in the beginning of the program. The last array item number is the higher position in the array effectively occupied when the initialization is going to be made.
The array would any standard one, containing no "zd" or "pd" variables:
Code: |
01 WS-ARRAY.
03 WS-ARRAY-ITEM OCCURS ...
05 WS-ARRAY-FIELD-1 PIC X(10).
05 WS-ARRAY-FIELD-2 PIC S9(09) COMP.
...
05 WS-ARRAY-FIELD-N PIC S9(04) COMP.
|
I also tried a combination of option 3 and 1, with no effect.
I wonder if there's a known way to initialize huge arrays that is better than the #3 above.
Thanks. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
I tried the following and the 3rd option seemed to be the best by far |
Quote: |
I wonder if there's a known way to initialize huge arrays that is better than the #3 above |
What do you mean by "best" and "better".
Quote: |
I also tried a combination of option 3 and 1, with no effect. |
What effect did you expect/want?
If the program runs too long or uses too many resources, how the array is initialized is not likely to be the cause/reason. . . |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
add a counter as part of the arry:
Code: |
01 WS-ARRAY.
03 WS-ARRAY-COUNT PIC S(9) COMP.
88 NO-WS-ARRAY-ITEMS VALUE ZERO.
03 WS-ARRAY-ITEM OCCURS ..
|
I have not initialized an array in 30 years.
I simply set the 88-lvl NO-WS-ARRAY-ITEMS TO TRUE.
add 1 when I need a new item;
set the index to WS-ARRAY-COUNT
and off I go. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Example #2 or #3 should be about as best as you can do. #2 will probably cause COBOL to generate an MVCL and initialize WS-ARRAY to all X'00's.
Perhaps #3 generates the same, but COBOL may generate a BALR to a COBOL runtime routine, because you're using a calculated length in reference modification.
When you turn on the Assembler compiler expansion option in COBOL (LIST,NOOFFSET), what instructions are generated for all three examples?
An MVCL will work for any target with a length not greater than 16777215.
For a length greater than 16777215, COBOL may generate an MVCLE or BALR to a COBOL run time routine.
If the length is under 257, COBOL will generate (with compile option OPTIMIZE) an XC or with NOOPTIMIZE an MVI followed by an MVC overlap. providing there isn't any reference modification length specified. LENGTH OF (reference modification length) will cause the compiler to think about how the initialization will work.
Regardless of the value in WS-USED-ARRAY-LENGTH, COBOL will either generate an MVCL or BALR to a COBOL run time routine, even if the length is under 257.
But, since COBOL II, you could use a VALUE clause and initialization is performed in the PROLOGUE code, which is the most efficient method.
Bill |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
If you have to initialize the array while the program is running (such as to reset it), method 3 is going to be your best bet. In a previous job, we had a million-byte array that was initialized (via method 1) once per customer (two to ten million times per run). By changing to method 3, we cut 80% of the run time out (by not initializing 80% of the array). |
|
Back to top |
|
|
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
Quote: |
What do you mean by "best" and "better".
|
Quote: |
If the program runs too long or uses too many resources, how the array is initialized is not likely to be the cause/reason. . . |
I mean the "fastest" way to initialize the array.
I agree usually this is not the reason for a program to run slowly.
As far as I know, db2 access is normally the most common reason.
However, when it comes to Cobol instructions, what we've seen is that the "search" and "initialize" commands are the most likely culprits.
Recently we had a few cases like the one mentioned by Robert Sample.
Two programs were changed to improve the way it was searching and initializing huge arrays and the result was outstanding: the program, that used to run in 26 minutes, is now running in 2.
In the specific case of this thread, I need to have the array physically initialized because some of its fields will be used as flags and counters.
I just wanted to know what kind of code people is creating out there to make sure we are doing it right here.
Thanks. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
As far as I know, db2 access is normally the most common reason. |
No, poor/sloppy implementation is the most common reason.
Unfortunately, it is quite common to see sql implementations that the only effort went into writing the least code. . . Usually a formula for performance disaster. And so database is blamed, not the poor design/implementation.
Depending on exactly what your array processing does, the searching of the array probably took much more than the initializing . . .
Another approach to very large arrays that are not completely used each iteration is to not initialize the whole thing at all. . . Maintain a high water mark and when the next array element is needed, move in the "real" values. . . This would of course depend on just what is happening in the code.
What works "better" or "best" depends on the whole process, not just getting zeros into the big array. If all that is wanted is some "low-hanging" fruit (i.e. easily gotten with little effort), changing the initialization may help. I suspect there are other more significant opportunities, but these would take detailed analysis and testing. . . |
|
Back to top |
|
|
|