Traditionally, COBOL writes printed output by defining a data structure in the working storage composed of fields and fillers, then the code moves data to be printed to the fields using MOVE verb (variations exist on this of course).
A possible alternative is to use STRING verb to construct the output line record.
The platform which I am targeting is IBM ENTERPRISE COBOL and I currently have no access to it! The program is expected to run using millions of records and the decision is fundamental before the coding starts. I am considering the STRING option since it is more flexible and may allow changing the print line format without changing the code in the future, this is a realistic possibility but not a concrete requirement.
My question is: I expect, but don't know for sure, that STRING takes significant CPU time. Would using STRING instead of MOVE cause a significant slow-down to the program (say more than 20%)?
I understand that the question is not very precise, and I don't expect anyone to have an exact answer unless that person has done a similar test, but maybe someone somewhere did a similar test and had a good guess based on that test.
Thanks.
STRING var DELIMITED BY SIZE into var-2 must be nearly as fast as a MOVE because it commonly goes down to the same CPU instructions. It could even be faster as a STRING doesn't do any type conversions, which MOVE does (and that is the one place where MOVE has "more power").
The more phrases you add to the STRING (which is of course in general the "more powerful" command) the more needs to be done at run-time so you get a slowdown, but then if you do the same on your own (like incrementing a position counter) it will be faster again to directly do this in one statement.
For performance it likely is more important what the code "around that" actually does, and "printing" sounds like file io (preferably file, possibly DB2) - and that is the place where you'll need to tweak for performance, not MOVE vs. STRING - just use what is most appropriate to get the task done - and watch out to use USAGE DISPLAY for variables that directly goes into "printing", and for counters and calculations the most appropriate USAGE (likely signed integers with COMP).
As always: the only way to ensure you get the best performance is actual testing on the target machine.