Will program size impact on performance?

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

I have a program which contains over 1000 lines, and the sources still keep growing in accordance with increasing requirement.
I'm considering of developing a subprogram, because I'm afraid that with the increase of sourcecode size, program performance will be brought down.

Can anybody please advise if there is a connection between program size and program performance?

thanks.

Bill Woodger · Posted: Wed Jul 25, 2012 2:01 pm

The biggest impact is going to be volume of data.

If you design your program so that you get something easier to understand and maintain, you won't be able to notice any performance drop just from lines of code.

Anuj Dhawan · Posted: Wed Jul 25, 2012 2:25 pm

I'm not sure why the number-of-lines-of-codes is being connected with the performance of the program?

Having less number of line of code might make it maintable but then "performance" is totally differnt animal.

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

thanks for your reply.

so, it's not necessary to worry about that.

Robert Sample · Posted: Wed Jul 25, 2012 4:42 pm

Program (load module) size can impact performance, particularly under CICS, but it is rarely the number of lines of code that is a concern, but rather the data structures defined in the program's WORKING-STORAGE. 1000 lines of COBOL code is actually a pretty small program; I've worked on many COBOL programs in the last 35 years, and the average number of lines of code is probably between 3000 and 4000. I have worked on programs with over 20,000 lines of code.

don.leahy · Posted: Wed Jul 25, 2012 6:01 pm

I don't start to worry about program size until it is over 5000 lines. And even then my concern is only about maintainability, not performance.

Not that smaller programs are necessarily more maintainable. I have worked on a system contained about 10 000 programs, each one about 150 lines. It was a nightmare to navigate through the code to figure out what was going on.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Not for nothing, but I'm curious as to WHY you thought this might be an issue.

Maybe, just maybe, there is something weird at your shop that has created this "old wives tale" and kept it alive.

Ask around and see if anyone knows why they are even thinking about that issue. Chances are it's nothing, but it may pay to check it out now.

Two things I can imagine is that you have an ancient sysprog that still thinks in "pages." Or that you have a newborn sysprog that thinks in Java and has never worked with compiled code.

Bill O'Boyle · Posted: Wed Jul 25, 2012 7:48 pm

MVS paging can greatly impact performance. If the program is COBOL and it's been compiled using the OPT(FULL) compiler option, then the compiler places PERFORM's of internal routines in-line to reduce paging. This can result in a load module which is greater in size than a load module without OPT activated during compilation, due to the redundancy, but better performance with reduced paging. OPT(FULL) generates more all-around optimized object code.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Bill,
Is this still true under z/OS (assuming that's different than "MVS")?

How do you check the amount of paging going on during a program run?

Are there system-level optimizations going on that attempt to load the entire program into core even without the OPT(FULL)?

Robert Sample · Posted: Thu Jul 26, 2012 4:58 am

Paging is less of a concern than in the past in these days of z/OS machines having gigabytes of memory available. However, when paging does occur it can have a big impact on the LPAR, so if there's any indications of paging that needs to be addressed. As far as I know, the way to check paging is to use a monitor such as Omegamon or Mainview or MXI. After the fact, analysis of SMF data can show paging as well.

dbzTHEdinosauer · Posted: Thu Jul 26, 2012 5:24 am

you know when your system is not tuned and a lot of paging is going on;
you have time to go get coffee after you have hit ENTER.