Originally Posted by jiml8

And again I will disagree. They spend a lot of time writing code for which speed is less important than other considerations.

I have in the past had to track down obscure bugs that occurred intermittently, and that seemed to have timing issues within them (I have NOT encountered this in Linux, though I have encountered it in a number of embedded systems, and in JOVIAL J73 code, and in ADA code...). Commonly, what I would find is that an uncommonly used error routine or an obscure branch was taking too much time to run, with the result that the mainline code did not have enough time to complete ITS job (typically a register won't get loaded in time). In the vast majority of cases, this came about because the author of the obscure branch said "speed isn't important" and spent no time on it. Thus, he used inefficient type transformations, or set up a loop without considering how much time that loop would take to run, and otherwise took more than his needed and fair share of processor.

So, he saved time coding, and we wasted time debugging a case that only occurred intermittently and was hard to set up to make it repeatable so we could find it. Such things never show up under debuggers; the debugger slows things down enough that the load of that register does finish before the mainline code tries to use the contents of the register.

You talk about time-critical code; that is pretty much all I do these days - embedded, signal processing, telecommunications type things. And again, I say unto you that speed IS important...always. It might be the least important of the criteria that are in front of you (schedule, budget, frequency that this code will run, space), but it is NEVER unimportant. And if you start with the assumption that speed is ALWAYS important, then when you code this branch you will say: "this loop might take awhile to run...I wonder if there is a more efficient way...how long would it take me to recode it that way..." or "this path will be taken if it is taken during a time critical operation, so what can I do to make it take less time to run..." At an absolute minimum, you could put a FIXME in the code, and send a memo to the boss: "I did it this way because of schedule pressure, but there is this potential problem down the line and if we encounter these symptoms we might want to look here".

I have seen loops in obscure paths in user code that would suck up 99% of the processor for milliseconds at a time, performing tests that didn't need to be performed. The person writing the code decided to handle "all cases" and "speed wasn't important".

When you say that speed is ALWAYS important, you are less likely to do such things and far more likely to have it at least flagged as a potential problem when you DO do it.

Speed is always, always, always important.

Originally Posted by Roflcopter

Do you have any suggestions?

Originally Posted by AceofSpades19

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” - Donald Knuth