View previous topic :: View next topic |
Author |
Message |
Dibakar Advanced
Joined: 02 Dec 2002 Posts: 699 Topics: 63 Location: USA
|
Posted: Thu Jan 02, 2003 2:00 am Post subject: Extra Variables vs Performance |
|
|
We are using COBOL-CICS program where we use (copy) some common copybooks of which only few variables and procedures are used. Though it is convenient to use them, I want to know if it affects performance. |
|
Back to top |
|
|
Manas Biswal Intermediate
Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
|
Posted: Thu Jan 02, 2003 2:48 am Post subject: |
|
|
I really would not think so. Copybooks are resolved at compilation time and by the time the load module is created, it would be practically the same if you would not have used copybooks and hardcoded the variables. I don't think there is any difference at run time.
Regards,
Manas |
|
Back to top |
|
|
Dibakar Advanced
Joined: 02 Dec 2002 Posts: 699 Topics: 63 Location: USA
|
Posted: Thu Jan 02, 2003 4:02 am Post subject: |
|
|
Manas,
Are you saying that unused variables and procedures will be filtered out at compilation state?
I was of the opinion that they will also go to load module and waste some memory during execution. |
|
Back to top |
|
|
Manas Biswal Intermediate
Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
|
Posted: Thu Jan 02, 2003 8:01 am Post subject: |
|
|
Oops Dibakar,
I am sorry. I re-read your original post. I had thought that you were asking the performance difference between using a copybook and hardcoding the same variables in the program. I did not consider the case when some variables in the copybook will not be used at all. In that case, it all depends on how far the copybook is convenient vis-a-vis the performance degradation on using unused variables. Yep, in this case, all the unused variables will also go to the load module. I don't think they will be filtered during compilation.
Regards,
Manas |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12370 Topics: 75 Location: San Jose
|
Posted: Thu Jan 02, 2003 10:33 am Post subject: |
|
|
Dibakar,
You can compile your program using OPTIMIZE(FULL) which will remove unreferenced data items from Working-Storage. It generates no code and takes no extra storage.
To assist in the optimization of the code, you should use the OPTIMIZE compiler option. With the OPTIMIZE(STD) or OPTIMIZE(FULL) options in effect, you may receive optimizations that include:
- eliminating unnecessary branches
- simplifying inefficient branches
- simplifying the code for the out-of-line PERFORM statement, moving the performed paragraphs in-line,where possible
- simplifying the code for a CALL to a contained (nested) program, moving the called statements in-line,where possible
- eliminating duplicate computations
- eliminating constant computations
- aggregating moves of contiguous, equal-sized items into a single move
- deleting unreachable code
Additionally, with the OPTIMIZE(FULL) option in effect, you may also receive these optimizations:
- deleting unreferenced data items and the associated code to initialize their VALUE clauses.
Many of these optimizations are not available with OS/VS COBOL, but are available with COBOL for MVS & VM. NOOPTIMIZE is generally used while a program is being developed when frequent compiles are necessary. NOOPTIMIZE also makes it easier to debug a program since code is not moved;
NOOPTIMIZE is required when using the TEST compiler option with a value other than TEST(NONE).OPTIMIZE requires more CPU time for compiles than NOOPTIMIZE, but generally produces more efficientrun-time code. For production runs, OPTIMIZE is recommended.
Performance considerations using OPTIMIZE:
- On the average, OPTIMIZE(STD) was 4% faster than NOOPTIMIZE, with a range of 17% faster to equivalent.
- On the average, OPTIMIZE(FULL) was equivalent to OPTIMIZE(STD).
- One RENT program calling a RENT subprogram with 500 unreferenced data items with VALUE clauses was 3% faster with OPTIMIZE(STD) and 5% faster with OPTIMIZE(FULL).
- The same RENT program calling a RENT subprogram with 500 unreferenced data items with VALUE clauses using PROGRAM IS INITIAL was 6% faster with OPTIMIZE(STD) and 80% faster with OPTIMIZE(FULL).
Note: The two RENT program tests measured only the overhead of the CALL (i.e., the subprogram did only a GOBACK); thus, a full application that does more work in the subprograms may have different results.
Hope this helps...
cheers
kolusu |
|
Back to top |
|
|
Dibakar Advanced
Joined: 02 Dec 2002 Posts: 699 Topics: 63 Location: USA
|
Posted: Fri Jan 03, 2003 7:27 am Post subject: |
|
|
Kolusu,
Ravi already said what I wanted to.
One question, is it really difficult to debug with optimize option? I haven't tried it yet but what I guess that coding might look a bit diffrent but flow will be same, right. |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12370 Topics: 75 Location: San Jose
|
Posted: Fri Jan 03, 2003 10:18 am Post subject: |
|
|
Dibakar,
Yes it would be little hard to debug the program with OPTIMIZE(FULL) option,as the code will be moved as it simplifies the code.
kolusu |
|
Back to top |
|
|
zatlas Beginner
Joined: 17 Dec 2002 Posts: 43 Topics: 4
|
Posted: Sun Jan 05, 2003 7:37 pm Post subject: |
|
|
Hi
The parts of COBOL you are using seem to be not the modern Object Oriented parts. This is usually the case with most COBOL programmers (including myself). However the first step toward object orientation (which is the rage nowdays) is to use standard objects and not worry about some wasted memory space or even negligable performance lose.
Your shop is correct on insisting on usage of common standard copybooks regardless if you use all data or parts of it only. Usage of standard object aloow centeral changes in one point rather than analyzing zillion programs one by one (remember Y2K).
Unless your company really does not have financial resources and has to resolve to use only 16M ( ) in the single obsolete S/370 taht is maintained with parts bought in the black market ( ) you should not worry about couple of hundred bytes of wasted memory when you consider the huge gains in maintainability.
ZA |
|
Back to top |
|
|
Dibakar Advanced
Joined: 02 Dec 2002 Posts: 699 Topics: 63 Location: USA
|
Posted: Tue Jan 14, 2003 9:16 am Post subject: |
|
|
Sorry for delay in responding as I was on leave.
ZA, nobody is forcing me to use common copybooks, infact I myself developed some (though only I use them, others find it easier to code themself). My concern, rather curiosity, was only on ease vs performance.
After reading through all the replies, I am glad that I put the question otherwise I wouldn't have been aware of techniques like optimization.
Thanks again. |
|
Back to top |
|
|
|
|