Re: Bug/Gross InEfficiency in HeathField's fgetline program

Antoninus Twink said:

On 9 Oct 2007 at 9:34, Richard Heathfield wrote:

<snip>

So in this case, the performance increase is meaningless, whereas the
loss of clarity is significant.

But exactly the opposite is true - clarity is lost in *your* version, by
taking something simple and making a meal of it.

Clearly, you are entitled to your opinion. Equally clearly, many here do
not share it, including me.

<snip>

It's terribly, terribly simple C. It's astoundingly easy for most C
people. I simply cannot understand why you would find it difficult or
complex.

Yes, it's terribly, terribly simple. Almost babyish even. I did not mean
that your *code* is complex, but that the *algorithm* is complex.

You're kidding, right? If you think that's a complex algorithm, steer well
clear of Miller-Rabin or Boyer-Moore (or, come to that, gcd).

And
you will say, "But it's a simple algorithm!" Right, it isn't complex by
any objective standard of complexity, but it's *more complex than it
needs to be* - why swap a simple single-pass algorithm for a 2-pass
algorithm?

I didn't swap anything. I just followed my programming instincts. It was a
long time ago, but I expect I reasoned roughly along these lines: (a) the
original might not be writeable, so make a safe copy; (b) hack the copy,
leaving the original alone.

During development, I would certainly have noticed if the performance were
unacceptable (because I tend to develop incrementally most of the time, so
sudden performance drops will normally stand out), and done something
about it. Since that never happened, I didn't bother. This is in full
accordance with the Two Rules of Optimisation.

And if you make simple things over-complicated, we might not
unreasonably suspect that you might make complicated things into a
complete mess.

You might think that my way is more complicated, and that's entirely up to
you. But John Bode's optimiser clearly disagrees with you.

By the way: if, for the sake of argument, we accept that my code /is/
grossly inefficient, how should we describe your code, which - on John's
system - is between 20% and 85% *slower* than mine?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • Re: Surrogate factoring mysteries resolved
    ... > Now combinations of factors are important, as the proper algorithm ... does the number of divisors increase in a cubic fashion? ... No one doubts that factoring is hard. ...
    (sci.math)
  • Re: Surrogate factoring mysteries resolved
    ... > Now combinations of factors are important, as the proper algorithm ... does the number of divisors increase in a cubic fashion? ... No one doubts that factoring is hard. ...
    (sci.crypt)
  • Re: can this code be improved
    ... Why "numberOf" AND "Count"? ... Now we can see what the algorithm is within a few lines of code. ... refactor it further or rewrite it entirely. ...
    (comp.lang.java.programmer)
  • Re: fmincon and simulink
    ... That's okay, users can *snip* out unnecessary sections when they reply. ... This warning just means that FMINCON is going to use a different algorithm ... since the error message indicated that your nonlinear constraint ...
    (comp.soft-sys.matlab)
  • Re: Bug/Gross InEfficiency in HeathFields fgetline program
    ... case, the performance increase is meaningless, whereas the loss of clarity ... Compare that to two lines of idiomatic code. ... We have already demonstrated why "slower" is unimportant. ... "But it's a simple algorithm!" ...
    (comp.lang.c)