🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.c.moderated
Article #2255

Re: use of the break statement

#2255
From: Richard Wells
Date: Tue, 12 Mar 1996 02:49
49 lines
2825 bytes
J. Kanze wrote:
 > 
 > In article <4hladl$4cr@solutions.solon.com> Andrew Dalgleish
 > <andrewd@axonet.com.au> writes:
 > 
 > |> [deleted code examples of break vs. testing flag at top of loop]
 > |>
 > |> 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.)

Mr. Kanze alluded to something I'd like to emphasize: let's not lose
track of the simple fact that generally whatever is happening inside
these loops dwarfs the time it takes the processor to check a simple
flag each time through the loop.  Write the code to make it readable
(IYHO), and worry about optimizing it for speed only after you've
determined the checking of the flag to be the expensive operation in
the loop.

Besides, if I ever needed to put a 0..10e6 loop inside another 0..10e6
loop, I'd look for a different algorithm before worrying about where
to check a termination condition.
Technical Details
Message-ID: <4i2oni$9k9@solutions.solon.com>
Path: arc1-ca.pugleaf.net!solon.com!not-for-mail
References: <4gfcl7$2ls@solutions.solon.com> <4gnbcp$biq@solutions.solon.com> <4h81gh$aql@solutions.solon.com> <4h9ml2$gub@solutions.solon.com> <4hqedf$1m0@solutions.solon.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!solon.com!not-for-mail
From: Richard Wells <rdwells@mmm.com>
Newsgroups: comp.lang.c.moderated
Subject: Re: use of the break statement
Date: 11 Mar 1996 20:49:22 -0600
Organization: 3M Company
Sender: clc@solutions.solon.com
Approved: clc@solutions.solon.com
Message-ID: <4i2oni$9k9@solutions.solon.com>
References: <4gfcl7$2ls@solutions.solon.com> <4gnbcp$biq@solutions.solon.com>
  <4h81gh$aql@solutions.solon.com> <4h9ml2$gub@solutions.solon.com> <4hqedf$1m0@solutions.solon.com>
NNTP-Posting-Host: solutions.solon.com
X-Mailer: Mozilla 2.0 (WinNT; I)