This performance tuning advice is applicable all programming languages, not just COBOL. It is such a simple piece of advice, you may just face palm yourself when you hear it, or you think "duh!" Those familiar with Lean and Six Sigma will be very familiar with this concept.
"Remove the code that is the slowest and do not execute it."
That's it. It's that simple. Of course, this is not always an option, but some times it is.
For example, most COBOL modules begin with an initialization paragraph where you are moving zeros, spaces, high values, low values, and so on to many work fields and copybooks. Many of these fields do not need to be initialized because the code is moving a value to them anyway.
For example, how many times have you created a field called SUB1 that you are using to access elements in an array? How many times have you moved zero to SUB1 in the initialization paragraph, only to later do a PERFORM VARYING SUB1 FROM 1 BY 1 UNTIL...? This statement is moving 1 to SUB1 on the first execution of the statement, so moving zero to SUB1 in the initialization paragraph was a complete waste of a code.
That one line of code may not seem like much, but when that line of code is executed a millions times per night, each night, for roughly 250 nights each year, it adds up. Now multiply that for each job you run in your batch cycles, your onlines, and the number of fields that are just like SUB1, and it really begins to make a difference.
Keep this tip in mind when you are coding, what ever you are coding in. Eliminate code, because MIPS are a terrible thing to waste.
And your CEO will thank you (okay, probably not).
Lon,
ReplyDeleteI don't mean to assign work to you, but since you are one of the select number that thinks about efficiency you might want to make a post about doing arithmetic between different data types, and then signed and unsigned numbers.
Keep up the good work.
jimc
Jim,
ReplyDeleteThanks for the comment. I do have a couple of arithmetic topics I will write about.
I've been told that floating point is supposed to be the fastest computation. I have not done any testing between data types, myself, so I'll need to do some searching to see if there are any metrics available. The same with signed and unsigned numbers.