Gabriel Sechan wrote: > > > Here's the problem with the idea of optimization at the end. CHanging the > code later is more expensive than changing it early.
Assuming I am correct, but optimisation includes things like changing i = i + 2; into i += 2; while changing f(int i); into f(char *i); would not. If you think that changing an interface is a valid optimisation technique, we can end this discussion now, as we have vastly different ideas as to what optimisation is. > Its cheaper to fix a bug in design than in coding, its cheaper to fix > it in coding than in testing. Yep. If you add ``It is cheaper to fix code before optimisation'' then you will get what the original quote said. > The same is true for optimization- a little time spent worrying > about performance early will make it a lot cheaper to achieve it than it > would be later on. Until QA throws it back saying ``this is buggy.'' > By the time you get to the end and try to optimize, you end up > spending large amounts of time trying to figure out what to optimize, > then an additional large amount of time doing so. Your profiler will show you where the bottlenecks are. You won't know that until it actually works. You can guess, but you will likely guess wrong. > And throwing out time already spent on the unoptimal solution. > Whereas considering performance in the planning stage requires no > rework or wasted time, and doing so in the coding stage requires much > less (you're already in the mindset and familiar witht he area of > code). Until you make the wrong guess, spend a lot of time optimising a section of code that, you thought would get run most of the time, ends up with .01% of the actual run time. http://en.wikipedia.org/wiki/Optimization_(computer_science) says something about this: First of all, it is extremely important to use a profiler to locate the bottleneck. Programmers usually think they have a clear idea of what the bottleneck is, but they are frequently completely wrong. Optimizing an unimportant piece of code will not help the overall program speed. It also says: Usually, the most powerful optimization is to find a superior algorithm. This supports your argument. > Yeah, you'll miss a bottleneck or 2 just like you'll miss a bug or 2, > but the end result is still a cheaper, better product than leaving it > to the end. You are reminding me of comparing two BASIC programs side by side. One was written to be legible, the other was written to take advantage of the way the tokeniser worked, to gain additional performance. One was legible, the other was not. If you tried to write in the most efficient run-time way, your debugging time increased by large amounts. However, if you write in a legible way, then debug, then profile, then optimise, you have leveraged the full force of your development model. That's all that is being said. I tend to agree with it. -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
