Subroutines vs PERFORM in COBOL

Sasi Kiran Patha · Posted: Wed Mar 14, 2007 9:21 am

Hi,

In our shop we came to know of a finding relating to
Subroutines vs PERFORM.

Suppose a PARA (module) is performed using PERFORM 9999 times.
If we code the Para as a subroutine module and call the subroutine 9999 times does the time complexity increase and hence the performance decrease.

There are 2 cases here again, we have to evaluate the time complexity
if the subroutine has Db2 cursors and the other case where the subroutine has no Db2 calls or has a mixture of Db2 cursors and
normal loop structured processing.

Is it more manageble using the perform module or a subroutine module
in case the subroutine is called from one program.

Regards,
Sasi Patha.

agkshirsagar · Posted: Wed Mar 14, 2007 2:51 pm

I think you forgot to put question mark/s.

(Please do that so that we can know exact question )
About management, I feel it is easier to mange it if it is in a para (using Perform)
Because,
1. routine is getting used in a single program
2. recompilation and stuff.

Hope to here from you soon.

dick scherrer · Posted: Wed Mar 14, 2007 7:51 pm

Hello,

One way to determine if you would use a PERFORM or a CALL if if multiple programs need the same process.

If several programs need the same logis, the CALL is usually preferable. If the routine is only needed in one program, the PERFORM is usually preferable.

Sasi Kiran Patha · Posted: Wed Mar 14, 2007 8:00 pm

Hi,

What about the performance?
If the subprogram has Db2 cursors and the subprogram will be called 9999 times say.
If the same Db2 cursors are processed in a Perform module which will be performed 9999 times.

Are the execution times and performance benefits same in both the cases?

Regards,
Sasi Patha.

dick scherrer · Posted: Wed Mar 14, 2007 8:32 pm

Hello,

Please realize that for the most part, a CALL and a PERFORM both cause a transfer of control to another part of the executable and then return to the next statement. I the CALL is dynamic, the called module must be loaded into memory as part of the first call, but when you are going to issue the CALL 10k times, that will not be even measurable.

If you are concerned about performance, the interaction with DB2 will have much more impact than the CALL/PERFORM.

As i mentioned earlier, CALL versus PERFORM is often (usually) determined by how many programs need the "common" code. If one - PERFORM, if multiple - CALL. There can be exceptions, but they should be looked at individually.

Sasi Kiran Patha · Posted: Thu Mar 15, 2007 9:27 am

hi,

PERFORM and CALL transfer control. I agree. Call should transfer control
to another adress space, adress space of the called program which should consume more resources.

Correct me if im worng.

Regards,
Sasi Patha.

dick scherrer · Posted: Thu Mar 15, 2007 7:00 pm

Hello,

CALL doesn't use "another" address space. The called module is loaded into the same address space ot the caller.

When you use a static call, the called code physically becomes part of the calling load module. If the call is dynamic, the called module must be fetched from the library at runtime, but as i mentioned earlier, if there are 10k calls, the one-time load will not even be noticeable.

Either way, if the called module is 100k, 100k will be needed for the called code.

TG Murphy · Posted: Mon Mar 26, 2007 8:51 pm

PERFORM will run faster than a dynamic CALL but the difference will not be significant 99% of the time. As Dick mentioned, your DB2 activity is by far the most important factor in determining performance. If your program is designed intelligently and you do your DB2 correctly, then you don't have to worry about anything else.

My group does a lot of performance work. We almost never worry about whether a piece of logic was performed versus called. There are some exceptions. If you are interested - just ask - and I will list them.

The decision to use PERFORM versus CALL will almost always depend on other factors. Packaging issues - maintenance issues. For example, if the code is shared by other routines then you want it in its own subroutine.