Re: "Goto statement considered superfluous" (was: If you were inventing C)

From: Howard Brazee (howard_at_brazee.net)
Date: 09/27/04 

Date: Mon, 27 Sep 2004 16:34:15 GMT

On 27-Sep-2004, "Michael Mattias" <michael.mattias@gte.net> wrote:

> > Is there a reason to shoot the person who writes the 1st version of this
> code,
> > saving 6 assembler moves per day?
>
> No, but I'd consider shooting the guy who wrote the second one, which does
> not terminate the lookup (EXIT PERFORM) when COMPARE-DAY =
> DAY-OF-WEEK(DAY-INDEX) and performs FOUND-ONE.
>
> Curious how sometimes the most obvious optimizations are those most easily
> missed.

I thought about that when I wrote this example - and decided that my point was
made better by leaving obvious ways to optimize the code without adding
significant obfuscation/cost.

It is interesting though that this "obvious" optimization is less obvious at
closer examination. I don't know how efficient the compiler is, for instance,
and I do know that adding an extra check does add some overhead. While my
assumption is the same as yours - it is obvious that coding an early exit is
more efficient than repeating the loop, I also see that 3 1/2 more iterations
isn't a big cost, and adding a comparison where a maintenance programmer might
make a mistake isn't quite as efficient as it looks.

Still, we both code for efficiency when the cost appears low.

Relevant Pages

  • Re: curried and uncurried functions
    ... Tuple construction is primitive, ... possible optimizations into account, we have 2 function calls and 3 ... outweigh the cost of constructing a simple pair. ...
    (comp.lang.functional)
  • Re: perf & Try Catch
    ... >> Having had a look at the JITted code, I think it's more a case of the ... >> JIT not being able to optimise as heavily, ... > difference in how aggressive the optimizations are). ... I think I'd say "virtually no cost" to give an appropriate ...
    (microsoft.public.dotnet.languages.csharp)