On Thu, 19 Apr 2012 04:42:55 +0200, Fritz Wuehler <[email protected]> wrote:
>[email protected] (Matthew Stitt) wrote: > >> Having said that, I still use GO TO extensively, and have not kept up with >> the "modern" programming extensions and constructs. >> I've had many instances in my career where a "structured" program has been >> "straight lined" with extremely dramatic performance >> results. Mostly I believe that knowing Assembler language and how the COBOL >> compiler would generate the assembler code version >> of the program provided the reasons for my coding techniques. I would write >> the program as close to what the assembler code >> would be as possible. This would usually provide some great performance >> at run time (and at compile time). > >and > >> One example (out of several) was a program which normally took 4-6 hours to >> do its magic. When I re-wrote it due to the necessity >> of adding more functionality, I went ahead and "straight lined" it according >> to the logic of what the program was supposed to do. >> When the re-write was finished, the new program took 20 minutes to run the >> first time it was in production. I have several other >> examples with these type of results. > >This gets back to what I said. PERFORM is net 5 instructions more *per >PEFORM* than two GO TOs so loops processing millions of records get very >expensive fast and avoiding GO TO and being forced to use PERFORM causes you >to create more loops than you would need with GO TO. Last time I looked, >COBOL doesn't inline PERFORM so you pay the penalty hundreds or thousands of >millions of times in a big program processing a big file. And paging is >usually worse because of the unnatural long branches caused byPERFORM, when >straight line coding with careful use of GO TOs would have reduced paging. > >> Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a >> perform. Went to the Well in the early-mid 80's over that >> one with a bunch of certain "whiz-kids" who were trained under the good >> doctors premises. > >Thanks for your post, it is what I experienced as well. Practical experience >beats the college boys every time, especially burnt-out duffers like >Dijkstra who never sold a line of code and probably never wrote one either. I am writing this as some one who used ALTER ... GO TO to replace PERFORM statements in DOS 360 COBOL. I had an article published in an issue of Technical Support, the magazine of the National Systems Programmer Association (now Network and Systems Professionals Association) telling how I cut the execution time of a compute bound run by over an hour (it was running on a 3081). The program was COBOL VS and the 1974 standard COBOL running on MVS. This included replacing PERFORM ... VARYING with simple PERFORMs and looping within the PERFORMed paragraph by using IF statements within the paragraph that would GO TO the paragraph being performed. I am grateful that I had the caveat in the article that the new VS COBOL II might change some of the optimizations. As someone who has looked carefully at the code generated by PERFORM on IBM 360/370/390/z series systems, starting with VS COBOL II 1.4, the first Ansi 85 IBM compiler the ball game changed. On COBOL VS (74 standard) and prior there were statements like MVC save_exit_address,exit_address MVC exit_address,return_address L R15,perform_paragraph_start BR R15 return_point DS 0H MVC exit_address,save_exit_address. There would be a L R15,exit_address BR R15 at the end of the perform range. With COBOL 85, if the paragraph being performed is entered by a PERFORM statement, and there is never a fall through to the next paragraph and there are no GO TO statements in the paragraph, depending on various algorithms the performed paragraph may be moved inline with all perform code eliminated. PERFORM ... VARYING went from being a pig to having very efficient code. PERFORM x THRU x-exit in most if not all cases will still require the same 3 moves with even the latest COBOL because of the semantics of COBOL. Based on presentations by Tom Ross at SHARE (IBM COBOL representative) and my reading of the generated assembler code, I changed my coding practices to make sure all GO TO statements were eliminated because they mess up PERFORM optimization. Code optimization I did that saved substantial time on that compute bound run for COBOL VS would have to have be redone to take advantage of the PERFORM optimization in VS COBOL II release 1.4 and newer. There were other things done that were valuable when using the COBOL VS compiler that became counter-productive with the VS COBOL compiler. With any major compiler upgrade, you should review the language reference manual and the programmers guide to see if changes should be made in coding style to take advantage of different ways of optimization or newer constructs. The IBM COBOL compiler optimizations (when OPTIMIZE is chosen) are designed to support good coding practices. I can testify to the code movement that I have seen in my programs. While there are still inefficiencies the quality of the generated code has improved immensely. Unless a program is consuming inordinate amounts of resource or needs drastic rewrite anyway, it is not worth the cost of coding and testing to optimize it other than using the best compile options. However, if response time is slow or the program is a significant factor in the time needed for a batch window then determining where the time is spent and coding to reduce it is worth while. The coding may be in SQL statements, improving data definition or curing bad code. In rare cases it may mean really checking the algorithms and doing obscure things that require good documentation for the poor soul who has to understand it six months in the future. Clark Morris ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
