🚀 go-pugleaf

In article <4hladl$4cr@solutions.solon.com> Andrew Dalgleish
<andrewd@axonet.com.au> writes:

|> Compare snippet 'A':
|> long	l;
|> for (l = 0L; l < 1000000L; l++) {
|>   /* Stuff before test */
|>   if (condition) {
|>     break;
|>   }
|>   /* Stuff after test */
|> }

|> To snippet 'B':
|> long	l;
|> {
|>   /* Extra braces to limit scope of bBreak */
|>   BOOL	bBreak = FALSE;
|>   for (l = 0L; !bBreak && l < 1000000L; l++) {
|>   /* Stuff before test */
|>     if (condition) {
|>       bBreak = TRUE;
|>     } else {
|>       /* Stuff after test */
|>     }
|>   }
|> }

|> Example B may evaluate "bBreak" a million times.
|> It is *possible* that "condition" never evaluates TRUE, 
|> so you've evaluated "bBreak" a 1,000,001 times for nothing.

If this is the case, I would suggest that you change compilers.  I can
imagine cases where the control flow would be complex enough that the
compiler might have problems simplifying it, but this is certainly not
one of them.

|> In most code I write, the break exit is the exception, not the rule.

|> Now compare snippet 'C':
|> long	l1;
|> long	l2;
|> for (l1 = 0L; l1 < 1000000L; l1++) {
|>   for (l2 = 0L; l2 < 1000000L; l2++) {
|>     /* Stuff before test */
|>     if (condition) {
|>       goto EXIT_BOTH_LOOPS;
|>     }
|>     /* Stuff after test */
|>   }
|>   /* More stuff after test */
|> }
|> EXIT_BOTH_LOOPS:;

|> To snippet 'D':
|> long	l1;
|> long	l2;
|> {
|>   /* Extra braces to limit scope of bBreak */
|>   BOOL	bBreak = FALSE;
|>   for (l1 = 0L; !bBreak && l1 < 1000000L; l1++) {
|>     for (l2 = 0L; !bBreak && l2 < 1000000L; l2++) {
|>       /* Stuff before test */
|>       if (condition) {
|>         bBreak = TRUE;
|>       } else {
|>         /* Stuff after test */
|>       }
|>     }
|>     if (!bBreak) {
|>       /* More stuff after test */
|>     }
|>   }
|> }

|> Pop quiz:
|> 1. How many times is "bBreak" evaluated?
|> 	Ans:	Anywhere from 5 to 1,000,003,000,002 times.
|> 	Note:	If you evaluate "bBreak" after the loop count, 
|> 		it's only 1,000,001,000,000 times.
|> 2. How many times do we *really* need to evaluate "bBreak"?
|> 	Ans:	0 times.

   3. How many times does a good compiler generate any extra code to do
	the evaluation?
	 Ans: 0.

|> Contrived examples perhaps, but if you apply this small principle 
|> in *every* loop in your application it all adds up.

Eventually, one does use such techniques.  After profiling has shown
that said program runs to slow, and that the time lost is in this
particular loop.

|> I have yet to see code which uses break/continue/goto which could not 
|> be re-written without them, but if used carefully they make the code 
|> clearer and faster.

The above examples certainly do not show how their use makes the code
clearer.  And only measurements can show whether they make the code
faster.  (Most modern optimizers just give up when they see a label, and
some also give up when they see a goto.  So with a good optimizer,
snippet C will actually run slower than snippet D.  Of course, side
effects due to paging or alignment will generally outweigh these
differences anyway.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone