I said:
Some day, maybe months out in the future a certain confluence of events happen and BOOM!! it is not "fast enough". You can NOT "measure" the speed!

Donald said
people often waste a lot of development effort trying to optimise code when it is completely unnecessary. The result is invariably an unmaintainable mess.

Donald, I totally agree with your statement about overoptimizing. I have seen examples of "optimized" code for a keyboard/LCD unit, which is crazy. However, the opposite suggested here which is to ignore the issue is just as likely to cause problems.

There are two issues about speed. One is that trying to "milk the last drop out" of a processor most often lead to problems. The other is to ignore the issue (be that by using too slow a processor or inefficient code) which is just as likely to cause problems.

Anyhow, I think that I can phrase it this way: design for effeciency, and make sure that is enough, if you at the end have to superoptimize to achieve sufficient speed or make it fit you have lost all hopes of being certain you have reliability.

Another issue mentioned (the one that got me onto my soapbox) was the suggestion of making easy (read sloppy) code and optimizing it later, that is as I titled "a disastrous approach".

The one MAJOR area in which speed can be achieved without risking problems is the meticulous choice of the memory area for a variable. If the method is "make coding easy, just use the LARGE model" leave me out,

Erik