🚀 go-pugleaf

In article <4i2k0n$8jd@solutions.solon.com> Andrew Dalgleish
<andrewd@axonet.com.au> writes:

|> 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.

Generally, the best way to save your boss money is to use a style that
is easily maintained, even if it runs a little slower.  Most code
maintainance isn't involved with speeding the code up, but with adding
features.

    [...]
|> 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.

The fact that the output is different could very well indicate a problem
in your code.  Many compilers will give different outputs according to
the optimization level if your code invokes undefined behavior.  (The
classical case here: your code contains order of evaluation
dependancies.)
-- 
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