To be fair: the kinds of "premature optimizations" that Knuth was talking about when he wrote that were worrying about individual instruction selection based on expressions in a high-level program, and/or re-coding some statement using inline assembly. Specifically, the quote is prefaced with an admonition to ignore "efficiencies in the small" "about 97% of the time."<div>
<br></div><div>What he did *not* say was that we should ignore performance altogether -- or even that we shouldn't care about performance before and during bring-up of our programs. In fact, the point of the article is that you should worry about the big performance things first -- I/O, algorithms, data structures. Only when all of those are optimal, does it make sense to do small-scale optimizations that give you some constant factor of speed-up.</div>
<div><br></div><div>I recommend you read it; the whole thing. It doesn't say anything like "you shouldn't consider overall performance when you're writing code;" rather the inverse! Design for performance; implement for clarity.</div>
<div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br><div class="gmail_quote">On Thu, Nov 3, 2011 at 6:35 PM, Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 2/11/2011, at 11:08 PM, Joe Armstrong wrote:<br>
> When the great old ones said years ago "Premature optimization<br>
> is the root of all evil" - they were using machines that by todays<br>
> standards were<br>
> incredibly slow. Even then they viewed premature optimization as evil.<br>
<br>
<br>
</div>Mind you, premature pessimisation isn't a good idea.<br>
I'm in the middle of a, um, discussion about the marking of two<br>
student projects.  Both of them involved comparing the performance<br>
of some algorithms.  Both of them had code that was a factor of<br>
4 to 6 *thousand* times slower than straightforward C.  I think<br>
that this makes their results meaningless, or at any rate useless,<br>
and that a project with such results deserves a low mark.  On the<br>
other side it is argued that these are well presented projects...<br>
<br>
Straightforward code using straightforward data structures is the aim.<br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>