From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 7 Apr 93 21:07:00 GMT From: arizona.edu!zippy.telcom.arizona.edu!basix.com!rharwood@arizona.edu (Ray Harwood -- Data Basix: (602)721-1988) Subject: Re: and then Message-ID: <7APR199314073871@basix.com> List-Id: In article <19930406.143008.278@almaden.ibm.com>, jnestoriak@vnet.IBM.COM writes... >At a recent code inspection, someone suggested that I convert a >series of and's to and then's "for performance". I expect that >90+% of the time all the conditions will be true anyway. But is >it really true that and then will get better performance than >and? I realize this is probably a compiler dependant question. >Also, I question the value of doing such a thing styllistically. >Any opinions? There is certainly nothing "wrong" with the short ciruit forms... please note this discussion applies to both AND THEN and OR ELSE. Indeed, as a contractor of Ada software testing, I try to convince my clients that short circuit forms should ALWAYS be used, unless there is a compelling reason to REQUIRE the evaluation of each and every boolean term in an expression! My suggestion: *Always* put the most commonly FALSE term at the BEGINNING of a string of AND THENs, and continue in decreasing order of frequency. That way as soon as the code runs across a FALSE term, the entire expression is declared FALSE and the appropriate action taken without further needless evaluation. This is PARTICULARLY efficient if there are multiple FUNCTION calls in the boolean expression; saving the overhead of just a few calls (especially, for example, in a loop) is well worth the "headache" of typing a few more characters. For OR ELSE, put the most commonly TRUE term at the beginning. That way, as soon as the compiler runs across a TRUE term, the entire expression is delcared TRUE and appropriated action taken. Note: There is no "short circuit" form for XOR... you just can't decide the outcome of an XOR without evaluating both parts! Ray ----- Ray Harwood | Data Basix | Adjunct Faculty, East Campus, Voice: (602)721-1988 | PO Box 18324 | Pima Community College FAX: (602)721-7240 | Tucson, AZ 85731 | Instructor in Ada and Pascal Internet: | rharwood@Data.Basix.COM | rharwood@east.pima.edu ** For info on Data Basix, send EMail with no subject to Info@Data.Basix.COM **