MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Extra Variables vs Performance

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming
View previous topic :: View next topic  
Author Message
Dibakar
Advanced


Joined: 02 Dec 2002
Posts: 699
Topics: 63
Location: USA

PostPosted: Thu Jan 02, 2003 2:00 am    Post subject: Extra Variables vs Performance Reply with quote

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
View user's profile Send private message Send e-mail
Manas Biswal
Intermediate


Joined: 29 Nov 2002
Posts: 382
Topics: 27
Location: Chennai, India

PostPosted: Thu Jan 02, 2003 2:48 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Yahoo Messenger
Dibakar
Advanced


Joined: 02 Dec 2002
Posts: 699
Topics: 63
Location: USA

PostPosted: Thu Jan 02, 2003 4:02 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Manas Biswal
Intermediate


Joined: 29 Nov 2002
Posts: 382
Topics: 27
Location: Chennai, India

PostPosted: Thu Jan 02, 2003 8:01 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Yahoo Messenger
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12358
Topics: 75
Location: San Jose

PostPosted: Thu Jan 02, 2003 10:33 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Dibakar
Advanced


Joined: 02 Dec 2002
Posts: 699
Topics: 63
Location: USA

PostPosted: Fri Jan 03, 2003 7:27 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12358
Topics: 75
Location: San Jose

PostPosted: Fri Jan 03, 2003 10:18 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
zatlas
Beginner


Joined: 17 Dec 2002
Posts: 43
Topics: 4

PostPosted: Sun Jan 05, 2003 7:37 pm    Post subject: Reply with quote

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 ( Sad ) in the single obsolete S/370 taht is maintained with parts bought in the black market ( Laughing ) you should not worry about couple of hundred bytes of wasted memory when you consider the huge gains in maintainability.
ZA
Back to top
View user's profile Send private message
Dibakar
Advanced


Joined: 02 Dec 2002
Posts: 699
Topics: 63
Location: USA

PostPosted: Tue Jan 14, 2003 9:16 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
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


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group