wgarvin wrote:hristo wrote:Here I disagree with you. The "other things" that can be improved are never-ending and it makes perfect sense to improve the little things that you are certain of, while still dwelling on the heavy/important optimization issues. This is a practical approach to improving software and it makes good sense, IMO.
It's important not to lose sight of the fact that every optimization has a cost. That there's a tension between "optimization" and all the other factors that lead to good code. Optimizing tends to make your code harder to read, harder to debug, harder to maintain and harder to change.
As a general rule the above is true.
There are, however, a few issues of a development cycle that must be considered, IMO.
First you are putting way too much blame on optimizations, painting a picture that is inaccurate. One shouldn't be discouraged to look for optimizations. In fact 'optimizations' should be considered a natural aspect of a proper development cycle.
The major issue is that people often try to optimize too early and that causes the low level optimizations (the ones that would yield minor improvements) to dictate higher level design decisions. This is not a problem of 'optimizations' but is instead a problem of improperly set goals and lack of experience.
As a piece of code becomes mature it also becomes more complicated -- and this is expressed in the general interdependence of the code.
The code can get harder to debug for a myriad of reasons, where extreme optimizations is just an example, but there are many others.
The code can become harder to maintain and change because of it's complexity and design, and this is completely independent of any optimizations.
The code is hard to understand if it lacks proper documentation, regardless of whether there are explicit optimizations or not. (.)
Putting undue emphasis on the dangers of optimization doesn't establish a proper attitude for those who want to (and in some cases must) optimize their software.
Optimization is no different than debugging your code ... it is just a part of the development cycle and the important aspect here is to outline when (and where) optimizations should occur.
wgarvin wrote:
Some times, the piece of code affected by the optimization is very small and localized and doesn't mess up the program very much, so its worth doing even if the gain is small.
Regression testing!
Opaque changes that enhance the software and can be regression tested are always a good candidate. (The situation becomes more intricate when such changes are in a piece of code that is a candidate for purge, but that is a different situation.)
In this sense, one must have a good idea (plan) of where the software is going to go and then make sure that it's [the software] foundations are solid.
The problem, often, is that if there is no clear vision (plan, design) by the developer and if there is no clear design then any optimization becomes an ad-hoc exercise.
wgarvin wrote:
Or maybe it affects a lot of code, but you can get big performance gains by doing the optimization and so its worth dealing with the decreased readability and maintainability.
The decrease of maintainability and readability is not function of optimizations, alone. Assigning such relation is misleading, IMO, and puts unreasonable burden (cost) on optimizations.
The interfaces (internal or external) that a program uses can (and should) hide any implementation details from the overall application complexity. It doesn't matter how "foo" is implemented so long as it behaves properly and doesn't violate the designed interface.
Before thinking about optimizations of any sort, one should concentrate on the overall design and define the proper interfaces that will be used within the application.
wgarvin wrote:
(Just remember to put comments everywhere in the code so that when you come back to fix a bug in it 6 months later you can figure out wtf it does!)
Here ... fixed the above, for you! (in bold)
wgarvin wrote:
And still other times, the gain from the optimization is small (like, less than 0.51% ?) and you are better off just writing the simple code that you will be able to maintain more easily later.
"Simple" being a relative term, in some cases, but otherwise we agree.
wgarvin wrote:
Simplicity is a very valuable thing when programming. A very valuable thing. Many people overlook it. Just remember that when you're optimizing some code and its growing to be 2x as long and 3x as complex as the original! Optimization has costs, and you only want to pay those costs if they are justified by real and significant performance gains.
Simplicity goes out of the window if you enhance the software in any way, even if you don't optimize it at all. Soon enough you are at a point where the software is way too complicated and there is no easy way out of that. So, again, "optimization" is not the root of the problem.
Regards,
Hristo
