I've worked as a consultant on too many projects where people have done these steps in reverse, never with a happy outcome. #3 usually produces code so obfuscated that #2 and #1 become difficult or impossible.
Yes, I can imagine making it efficient often produces hard to read code..
Which, ironically, makes it less efficient -- as the code becomes harder to understand, people are less likely (or less able) to work on it. That's why you should never optimize *anything* unless
(a) the optimization is trivial and does not hurt code readability (i.e. it's just basic good software engineering), or
(b) you've proven, through extensive profiling and real-world testing, that optimization of that specific code will bring a significant speed-up to the *entire* project.
Sometimes the premature optimizations are just wrong -- lacking real testing and experience, people optimize for the wrong case and actually make the program slower. Other times, they make the code so hard to understand that they slow down development and kill the project. Still other times, the code that was originally optimized misses out on future optimizations (such as hardware acceleration) because it's too hard to fix, and ironically becomes the bottleneck after all. None of these outcomes is good.
All the best,
David
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
