Optimizations are worth the effort
I've been told before not to optimize. Now, obviously you don't optimize as you code. But when I get told things such as "don't optimize because computers are so fast now that there is no need," I get frustrated. Why not? Isn't speed always an issue? Yes it is, and no matter how fast your computer is, you will always want it faster. So why not optimize your software to help with that?
Its true that compilers will optimize your code at the assembly level. But they can't do evertyhing, because they don't know exact context and purpose behind each segment of code.
I, a perfectionist, could not release software that isn't the best I could possibly make it, even if I'm not getting my money's worth.
What they probably mean is, don't optimize too early, or don't optimize things that are too troublesome and the compiler will take care of anyway.
Optimization will allways be needed, because the faster the computers get the lazier the programmers get, and the lazier they get, the worst the code gets.
There will allways be margin for a good deal of optimization, just not like the olds days. Optimization these days is best acheived just by using the right algorithms for the right jobs, and there are a lot of lazy programmers out there that just can't be bothered to do just that.
Optimization will allways be needed, because the faster the computers get the lazier the programmers get, and the lazier they get, the worst the code gets.
There will allways be margin for a good deal of optimization, just not like the olds days. Optimization these days is best acheived just by using the right algorithms for the right jobs, and there are a lot of lazy programmers out there that just can't be bothered to do just that.
Optimizations:
case 1: obvious ones. the compilers almost always do these
case 2: algorithm ones. the programmer should always do this, in the design phase
case 3: abstraction-breaking ones. these should, as a rule of thumb, never be done unless the program is unusable otherwise.
1&2 pretty much everyone does.
you'd be arguing for case 3. doing case 3 makes code harder to maintain. doing case 3 makes code harder to debug. doing case 3 can often introduce bugs.
there's a reason why case 3 is discouraged beyond the reasonable levels.
case 1: obvious ones. the compilers almost always do these
case 2: algorithm ones. the programmer should always do this, in the design phase
case 3: abstraction-breaking ones. these should, as a rule of thumb, never be done unless the program is unusable otherwise.
1&2 pretty much everyone does.
you'd be arguing for case 3. doing case 3 makes code harder to maintain. doing case 3 makes code harder to debug. doing case 3 can often introduce bugs.
there's a reason why case 3 is discouraged beyond the reasonable levels.
*shrug* In the real world "doing your best" translates directly to "doing your best in the time you're given". If my game runs acceptably fast, I'm not going to waste time optimizing when it could be better spent doing gameplay balancing or bug hunting.
Quote:Original post by C-Junkie
Optimizations:
case 1: obvious ones. the compilers almost always do these
case 2: algorithm ones. the programmer should always do this, in the design phase
case 3: abstraction-breaking ones. these should, as a rule of thumb, never be done unless the program is unusable otherwise.
1&2 pretty much everyone does.
you'd be arguing for case 3. doing case 3 makes code harder to maintain. doing case 3 makes code harder to debug. doing case 3 can often introduce bugs.
there's a reason why case 3 is discouraged beyond the reasonable levels.
I agree! People tend to desagree in case 3.
I personally give slitly more points to optimization then code mantainability/debugging, so in rule 3 i'de go for, not breaking the abstration too much, instead of not breaking it at all =). But remains a very good point imho.
A lot of this applies to the eternal search for a perfect interface / design. You can waste time looking for something that doesn't exist or spend time with grease on your elbow a plenty.
Quote:Original post by squicklid
no matter how fast your computer is, you will always want it faster.
Contrary to the saying, good enough really is good enough. :)
Beyond that, any time spent optimizing can usually be put to better use improving the behaviour of a program.
80% of the time is spent in 20% of the code.
You don't optimize until everything else is done, not on a hand-recoding level. It's critical to identify that 20% code that needs optimization. I might be able to save a second in initialization code, but if I had spent that same time analyzing a frustum cull procedure, I might have saved 1 ms per frame, which is arguably far more important.
You don't optimize until everything else is done, not on a hand-recoding level. It's critical to identify that 20% code that needs optimization. I might be able to save a second in initialization code, but if I had spent that same time analyzing a frustum cull procedure, I might have saved 1 ms per frame, which is arguably far more important.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement