🚀 go-pugleaf

J. Kanze wrote:
>=20
> In article <4hladl$4cr@solutions.solon.com> Andrew Dalgleish
> <andrewd@axonet.com.au> writes:[snip]
>=20
> |> 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.
>=20
> 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.
>=20

You would hope so.

[snip]
>=20
> |> 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.
>=20
>    3. How many times does a good compiler generate any extra code to do
>         the evaluation?
>          Ans: 0.
>=20
> |> Contrived examples perhaps, but if you apply this small principle
> |> in *every* loop in your application it all adds up.
>=20
> 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 agree that modifications for speed whould only be done after=20
using a profiler. There's no point improving something only done=20
once on startup, etc.=20

But if you can change your work habits to write the best version=20
you can in the first place you can minimize the $$$ cost of=20
re-working, re-testing.

If this means writing code which you find personally unpalatable=20
but which will save your boss money in the *long* term, do it.

>=20
> |> I have yet to see code which uses break/continue/goto which could no=
t
> |> be re-written without them, but if used carefully they make the code
> |> clearer and faster.
>=20
> 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, an=
d
> 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.)

Clarity is in the eye of the beholder.
Call me lazy, but my personal preference is to do less typing and=20
less reading.

Optimizers aren't all they're cracked up to be.
An article in a recent magazine (I don't have it at hand - I'll=20
see if I can find it) compare the optimization of several commercial
compilers. Most compilers did very poorly. I don't think any of them=20
could optimize a loop built entirely with if's and goto's, yet all=20
the common loop constructs can be simulated this way.

One of the tests I perform before releasing software is to compare=20
the output of identical programs compiled both with & without=20
optimization. Unfortunately they often produce different results,=20
at which point I turn the optimizer off. That way I only have to=20
get rid of the bugs I have written, not someone elses.

> --
> James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft=
.fr
> GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, Fra=
nce
> Conseils, =E9tudes et r=E9alisations en logiciel orient=E9 objet --
>               -- A la recherche d'une activit=E9 dans une region franco=
phone

--=20
Andrew Dalgleish
Senior Software Engineer
Axon Research, Pty Ltd
6 Wallace Ave
Toorak, VIC
3142
AUSTRALIA
Tel:	+61-3-9826-5538
Fax:	+61-3-9824-0083
Email:	andrewd@axonet.com.au