Edward Jaffe's already cited point, that <begin extract> The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. </end extract>
is fundamentally important. Optimizers distinguish many special cases of each of these figures, generating slightly but significantly different code for each of them. A routine that is comprised chiefly of instances of these figures is thus easy to optimize, and this is often the case even when these figures are used less felicitously than than they should be. An optimizer can mitigate the bad-performance effects of ugly code. It must, however, be remembered that the code generated for, say, a DO WHILE or a DO UNTIL contains and makes critical use of unconditional branches. They are indeed implicit in these two figures and, of course, in IF-THEN-ELSE too. The question when GOTOs, i.e., unconditional branches, should be used explicitly is thus the interesting one. I myself use them where 1) I judge that they confer a significant performance benefit and 2) they can be used in a regular/orderly way. IN looking through code that I have written recently for instances of them I discovered something that I had not really been aware of. I use them most often to unwind recursions and for catastrophic error-handling. If, say, in traversing a binary-search tree recursively in some key sequence I find what I want, I use a 'stack-cleaning long branch' to return to the point at which I began the traversal. This 'out-of-block GOTO' is not strictly necessary; but the alternative, a sequence of several stack-unwinding returns, is ugly and slow. To summarize now, there are, I think, situations in which explicit GOTOs are appropriate, in which their use can confer significant, readily measurable performance benefits. Unfortunately, these situations are also highly problematic. To use GOTOs effectively in them one needs to know more about run-time dynamics than most programmers now know or are, I fear, ever again likely to be taught. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
