Sign in to follow this  

Optimizations are worth the effort

This topic is 4836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
*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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by squicklid
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.


First, you have to take into account the factor of diminishing returns and project limitations. There is a 'good enought' level of optomization that fits your wanting to make a 'proper' program and how much time you are allowed to do it in.
The rule of 90/10 where 10% of the code does 90% of the work can be a good starting point of where to expend the most optomization effort.

Second, it may depend on how people define 'optomization'.
Is picking an optimal algorithm for the problem 'optomization'?
(versus a KISS brute force methodology which may so bad that you have to do major rework to substitute an acceptable performing methodology??)
Data structures and processing flow follow what algorithms are chosen (ex - minimizing data can greatly effect speed due to cache hits/misses).
I design with numerous optomizations in mind from the start and my choice depends on applicability to limitations of the problem (ie- static arrays vs dynamic allocation, and node pool freechains vs general garbage collection offer major speedups if the data has a known finiteness...)

These are all high level optomizations (in my opinion) and further 'low level' optomizations have to be done after the program is mostly complete.




Share this post


Link to post
Share on other sites
Quote:
Now, obviously you don't optimize as you code.

Depends on what you mean by "optimize."

Quote:
Yes it is, and no matter how fast your computer is, you will always want it faster.

You are begging the question. In many apps the application is I/O bound, meaning that it spends a great majority of the time doing I/O. Now, unless you are writing device drivers, you clearly cannot optimize the I/O routines except to avoid them if at all possible. But if your application is driven by an event loop, you have no choice but to block while waiting for the next event.

Quote:
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 is best?

Minimal executable size? Maximal speed? Minimal use of the heap? Or fixed-size buffers all over the place? In the last two examples we see something that could directly affect the user experience but otherwise provide some speedup.

I define best as tight, readable code. Tight does not always mean fastest -- just focused. Performance is just fine. If you wish to trade readability for minute performance gains, be my guest. Do know that it is not an effective use of time -- something that you may have considerably more of. While it would certainly be nice to sit down and optimize all the code I have written, it'd be an utter waste of time -- I know exactly where my bottleneck is, and can remove it by commenting out a single line. I would much rather add features or improve the UI.

I find the fascination with speed a bit strange...perhaps it is because C++ is so widely used around here. But we should really be careful about what languages whisper into our ears.

Share this post


Link to post
Share on other sites
If only it were so easy to tell what the 'optimal' solution really is. I'm writing AI for my space game right now, and it's hard enough trying to work out how to stop fighters crashing into things reliably, let alone doing it the fastest way 100% of the time (if that's even possible).

I've been through the perfectionist stage, and it doesn't work. Nobody's become famous because they made a 10% faster quicksort, but only when they actually got something done.

Quote:
Original post by Diodor
By the way, I take pleasure in finding ingenious ways to waste CPU clocks to make my code a wee bit easier to write or read.


My favourite at the moment is to use std::set whenever I want to keep a list of object pointers. It's far easier to maintain than a linked list for many situations.

Share this post


Link to post
Share on other sites
Quote:
hh10k
My favourite at the moment is to use std::set whenever I want to keep a list of object pointers. It's far easier to maintain than a linked list for many situations.


Mine is not to use C/C++. I enjoy not having to care about out of bounds errors and buffer sizes and obsessive type declarations in my Lua code so much I almost feel guilty for it.

Share this post


Link to post
Share on other sites
It isn't that you shouldn't optimize, but rather you should only optimize to fix a performance problem. A simple example is that your framerate is to low. There's a problem. That implies you have some level that you consider to be adequate. So you have a performance goal, i.e. get your framerate to an adequate level. The importance of that cannot be over-emphasised. It gives a direction to what you are doing. Just as having some idea what you want the program to do gives direction to your coding. Rather than spending a lot of time performing virtually random optimizations to your program you are better off spending the time understanding what affects your frame rate and how it affects it continuing that example. So you should never go through your program line by line looking for stuff to optimize. You optimize the program, not the lines of code.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by hh10k
If only it were so easy to tell what the 'optimal' solution really is. I'm writing AI for my space game right now, and it's hard enough trying to work out how to stop fighters crashing into things reliably, let alone doing it the fastest way 100% of the time (if that's even possible).

I've been through the perfectionist stage, and it doesn't work. Nobody's become famous because they made a 10% faster quicksort, but only when they actually got something done.

.



No, but game have failed (not sold well) because they were just too slow.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Diodor
Quote:
hh10k
My favourite at the moment is to use std::set whenever I want to keep a list of object pointers. It's far easier to maintain than a linked list for many situations.


Mine is not to use C/C++. I enjoy not having to care about out of bounds errors and buffer sizes and obsessive type declarations in my Lua code so much I almost feel guilty for it.



And I need the speed of C++ (doesnt LUA usually run at least 10X slower....) and even then Im farming AI out to seperate clustered CPU's...

Share this post


Link to post
Share on other sites
Quote:
Original post by squicklid
I've been told before not to optimize.


Who told you that?

I'd suggest making whatever it is you're working on work first as a whole. E.g. a class, a library, a game component, a whole game. Test it to make sure it passes all your tests.

Now that you've finished the component (whatever size it is), refactor it into a better design.

Now profile it.

Look for further problems in the design which, if improved may also cut out the performance hogging parting of your design. So only make optimisation changes which also improve the design. If there doesn't seem to be anything you can do without making the design less obvious, don't do anything.

Refactor if possible.

When you finally build your whole system, profile again. You may find that the components that you didn't optimise aren't a performance hog anyway as they're not used much. You may find that the software runs more than adequately on the target systems specs. Resist optimising.

If performance isn't good enough for your target system, then optimise. Again, first look for higher level changes that can be made, initially to improve the design of your system. Once you have cut down useage of the intensive components start looking to optimise them.

So, you don't just optimise at the end of a project, but you do put it off until it's not a waste of your time: I.e. your program works correctly, it is well factored, the system is close to its final state of usage, you know that the code you are optimising isn't going to be thrown away anyway, you have measurable evidence to show that your optimisations work and are worth reducing the obviousness of your code.

See Yet Another Optimisation Article.

In short:

1) Don't optimise
2) (For experts) Don't optimise yet
3) Use a profiler

Share this post


Link to post
Share on other sites
Quote:
Original post by petewood
Quote:
Original post by squicklid
I've been told before not to optimize.


Who told you that?


Quote:
Original post by petewood
In short:

1) Don't optimise
2) (For experts) Don't optimise yet
3) Use a profiler

[/quote]

However, I agree with everything that you just said there Petey boy.

Share this post


Link to post
Share on other sites
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.


Discouraged, but not always a bad idea. It depends on the application you're writing, and what part of the code it's in. If you're writing a normal front-end GUI Windows application, it is a bad idea to do it because the user should never notice the difference. In some of the less taxing games it is a bad idea because the game runs fast enough on current hardware.

In the games that really push the envelope (or back-end processes that can take a really long time), there are plenty of places in the code that it may make sense to break abstraction. Of course, you don't want to do it in a place that will gain you 0.01 FPS or less. ;-)

Sean

Share this post


Link to post
Share on other sites
Quote:
Original post by squicklid
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.


As a perfectionist your primary concern should be making sure there are no bugs, which means keeping your code clean and easy to maintain. When your code is a mess, it is easy to have two or more bugs pop up for every few bugs you fix. You should still optimize and make it as fast as you can, but not at the expense of making it difficult or impossible to fix.

Share this post


Link to post
Share on other sites
Offtopic: I just had to say this

Quote:
Original post by hh10k
Nobody's become famous because they made a 10% faster quicksort, but only when they actually got something done.


If someone managed to write a generic quicksort that was 10% quicker than anything else, they would be very famous very quickly. Over large data sets 10% can be a LOT.

/offtopic

Share this post


Link to post
Share on other sites

This topic is 4836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this