Oh, very interesting. So you want to *follow* an "IF" and let it run its
course, so to speak, rather than interrupting the most likely course with
an IF that is not triggered, so the pgm then must look for the proper EI
and jump to it.
Reply to note from Harry Binswanger Mon, 19 Oct
2009 09:18:30 -0700
> Separately, I note that you once again use a long IF . . . EI
> rather than (as I did) disposing of the U2-save case right
> away, by IF [...U2...] JM 2.LH then doing the non-U2 stuff
> "free and clear." Since you do this long-IF structure
> regularly, you must have a reason for preferring that. Which
> would be . . . ?
Optimization. The more the flow of execution jumps around (to LaBels
or EndIfs), the slower the program. So, other things being equal,
you want to structure your code so that there are fewer hops to
EndIf more of the time (and as few GoLabel...LaBels as possible).
Therefore, in conditionals, you put the condition more likely to be
true in the IF statement, and leave the less likely one for EndIf.
In your frame HBSA, most of the time, when you launch it, you'll be
editing a file other than U2. So the condition where VA$FP is not
equal to VA$U2 goes into the IF statement:
>{not equal to}>... do the SAve ...
and the call to LOADHELP goes after the EndIf:
JM 2.LoadHelpQ2 .
One of the countless things Robert taught me.
--
Carl Distefano
cld@xxxxxxxx
Harry Binswanger
hb@xxxxxxxx