If your average buffer-length is 100 (think compressed address), there's a three-percent CPU reduction irrespective of anything else (all processing is otherwise identical), grows with a smaller average, reduces with a larger.
Depending on what is within the IF (it may be, and I'd hope is, already dealt with), there could be the near-same boost for each compression. For subscripting, fastest is to use a literal, second, for a one-byte-entry table, is data-name-as-subscript, third is index-as-subscript, fourth is any other data-name-as-subscript. However, that is "general", more specifically if the number of entries in the table is less than 10,000, a PIC 9(4) binary data-name will be faster than the index, but don't make the binary COMP-5 nor use TRUNC(BIN) because the results will be wasteful. So, a one-byte table REDEFINES with a data-name-as-subscript is a good choice. However, it will be entirely equal (likely, 100% the same generated code) to the reference-modification example, because the "start position" for a reference-modification is behaving like subscripting-a-one-byte-entry-table-with-a-data-name. ADDRESS OF is a nice shot, not many would come up with that, but... with the optimizer turned off, you need to be referencing five fields by subscripting for this to pay-off (for the referencing-by-subscript to outweigh the establishment of the address), and with the optimizer on, the optimizer beats by only doing one "calculation" of the subscript, rather than one per reference. As always with tuning there is "better algorithm" (and sometimes that's enough, for the boss), and the fullness of that depends on the knowledge of the data. If the exercise were not academic, we'd need the fullest information about how it works now (and only yes-and-no does that mean the assembler code, largely no). "better code" comes down to applying what is known of the data with what the programmer knows of COBOL. Then there's what I call "straight spaghetti", by which I mean "code which runs in a straight line but which is horrible to consider maintaining because it is only written like this for extreme performance" - hopefully code like that has a short lifetime, whilst the underlying problem is fixed. Yes, straight-spaghetti may well snap when trying to stuff it into a pipeline. Be aware that things which were "fact" in the past may no longer be so. Various "rules" under OS/VS COBOL and earlier, handed-down from programmer to programmer through the years, just don't apply, and haven't applied for many years. Feel entirely free do define your data-name-as-subscript field to be PIC 999, with no sign... although, can I be certain with v3...? Well, you can test it, since you have V3 :-) OFFSET. That data-name wouldn't be chosen by a COBOL programmer from days-of-yore. It was drummed into me to not use single words, but to always combine with a hyphen at least two words. Why? Well, you never know (and this is from the experienced people) when the compiler would come along with a new RESERVED WORD. And since, at the time, only one of reserved words (or some other very small value) was hyphenated, we got "don't use single words, and don't use two words which when combined might look a bit computery to some future compiler-writer". I have since done my share of drumming. About three years ago, I discovered this: with the "COBOL 80 fiasco", for COBOL 85 they decided on "overloading" to provide new functionality where it was remotely... er... reasonable. So, there are now, in Standard COBOL, seven formats of SET. There are six formats of EXIT, with the high irony that FORMAT 1 is a no-op, FORMAT 6 covering two distinct behaviours, and which, along with FORMAT 5, implements "structured" ways to do GO TO without the effort of typing it or the certain knowledge of its destination (oh, for sure, the compiler knows). Anyway, when you have one piece of COBOL vs another, how do you know which is "faster"? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
