Skip to main content
gamedev.net
🔒 Locked

optimization....

Started by MSW Oct 27, 2002 at 7:17 PM 37 replies 700+ views
Original Post
MSW
MSW
when do you plan on doing optimization? case in point...You design up a nice workable pipeline to render graphics or whatever...get it running...and find that the frame rate isn''t to good. but because the "programmer laws" say not to optimize early...you keep trucking away until you have most every feature coded...and now the frame rate is even worse. you now have spend some 6 months on a project, and performance is degradeing everyday. so you run a profiler...and start optimiseing on the offending functions...the frame rate picks up to about where it was originaly (which was to slow to begin with). so you keep at it...getting near the point where you are starting to think of inlineing assembly...when it dawns on you, that much of the performance problem could be solved by radicaly redesigning the pipeline...but that would take a whole lot of work to convert the existing pipeline...so either you plow ahead, or start over with a "clean sheet" (but that is hard to do)... If you only stopped way back after you first got it up and running and saw the disapointing results...you could have potentialy saved yourself four monthes worth of work. So why do "programing laws" tell you to wait until the end to optimize?
CWizard
CWizard
I''m usually all for optimizing while you''re coding, but in this case you answered your own question. It would probably have taken longer if you optimized from the beginning, only to find that you need to redesign everything, and loose all optimization you''ve made.

The key is to design before you code, and hopefully you would come up with the best design first. When I say "optimizing while you''re coding", I don''t mean inline assembly or similar stuff that takes extra time, but rather these little optimizing tricks with loops and stuff, that aren''t very funny to do in a later stage.

---------------------------------------------
"VB is a disease"
CodeJunkie
CodeJunkie
quote:

So why do "programing laws" tell you to wait until the end to optimize?


Well in most cases when first developing any type of software most people tend to learn all the factors involved(speed vs ease of use, etc..) with implementing it after they have got a working idea(stable codebase). Then you will have a better chance to improve the design for more specific/quicker designs.

By the way nobody just knows exactly how to develop the quickest solutions right off the top of their heads.(unless you''re a creative genius) It takes time to develop a broader understanding of the problem you are trying to solve first.

After, programming on and off over the years I''ve come to believe that to optimize last is the best way to go. However, Yes that might mean you will have to throw away some code while developing.

P.S. Good Luck and stick with it because the more you do the better you will get.
MSW
MSW
I was reading a interview with John Carmak...in which he describes his willingness to "throw out code" and start over if he sees that something isn''t quite working right.

I''m not haveing optimization problems yet (I''m still at the design stage)...and just figured out a better way to store data...a way that would allow the engine to work faster then the previous implamentation design...and it just made me think of what could have hapened if I had started codeing useing the old model...may have never thought of the new one, until it was to late...and unlike Carmak, I don''t think I could throw out my code
Advanced Bug
Advanced Bug
First, the "optimization law" IMHO is more like "optimize when there is a real problem" rather than "start optimization only after coding the whole game", so probably engine optimization still must be done before writing most of game-specific code. I think that the main reason not to optimize early is to avoid optimizing parts of code that actually doesn''t need to be optimized.

Also the situation with completely redesigning the engine to optimize it, looks somewhat unrealistic - from my experience (not that it''s very big ) optimization is more like replacing some simple, but ineffective code with faster, but more complex code.

What about Carmack throwing away his code, I believe that it''s more about preventing code bloat, than optimization. If I see that some 1000 lines of code, can be replaced with, say, 300 lines of code with equivalent functionality, for me it seems to be a good idea to rewrite the code.
Qw3r7yU10p!
Qw3r7yU10p!
I''m reading Refactoring by Martin Fowler at the moment. It''s a great book which provides simple steps to take to rearrange your code with out adding any functionality and without introducing bugs. Sounds pointless? Well not really. Once you''ve rearranged things, thrown out redundent stuff etc. it puts you in a better position to extend, optimise, further rearrange, whatever you need to do.

If you feel that you need to totally scrap a design in order to get it working how you want then that''s a real shame. You should be able to refactor it.

It sounds like a lot of work but (apparently) if it becomes your discipline for development it actually reduces development time used bug hunting, and increases flexibilty and comprehensibilty of your code. Good Things.

If your design becomes a good design then the changes needed to optomise your code should be relatively easy to introduce.

That''s the theory, I''ve yet to practice it...
Arild Fines
Arild Fines
Redesign/change of algorithm != optimization.


Faith. n. Belief without evidence in what is told by one who speaks without knowledge, of things without parallel. -- Ambrose Bierce
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
Qw3r7yU10p!
Qw3r7yU10p!
quote:
Redesign/change of algorithm != optimization


I understand what you mean but that is a bit extreme. If you put in a better algorithm your code can be more optimal.

Really, I guess the optimisation you're refering to is the very end tweaking, when everything is in place, you've followed the rules 1)don't optimise, 2)don't optimise yet, 3)optimise where you have proof you need it. And now you're finally doing that.

I was responding really to the OP's comment that the two options are to 'plow on' or to 'start over with a clean sheet'

For example, if you found the main problem was that your data structures were just all wrong and causing all kinds of accessing inefficiencies but by changing them you would have to touch just about every part of your code, you've got a problem. Refactoring will mean you tackle it head on and rearrange it rather than compound it by 'plowing on'.

If you have extreme performance problems the largest improvements you will get are by redesign not tweaking.

edit:spelling

[edited by - petewood on October 28, 2002 6:44:27 AM]
SabreMan
SabreMan
quote:
Original post by MSW
but because the "programmer laws" say not to optimize early...you keep trucking away until you have most every feature coded...and now the frame rate is even worse.

There''s no "law" which supercedes judgement. You don''t have to wait for the end of a project to profile if measurements show that something is too slow for its intended purpose.
quote:

So why do "programing laws" tell you to wait until the end to optimize?

They don''t. They tell you premature optimisation is the root of all evil. They also tell you to profile before determining where a bottleneck is. What constitutes "premature" depends upon a number of factors, and is open to some interpretation.

The real problem is those people who engage in some sort of macho show of misguided optimisation activity because they''re "real programmers". This seems particularly rife amongst games programmers. Actually, it can be easy for normally sensible programmers to get drawn in that direction too. You have to remember that any time spent optimising is a complete waste of time and money until you know the thing you are optimising is going to cause a performance problem. Until you are certain of that, you are premature.
Qw3r7yU10p!
Qw3r7yU10p!
quote:
petewood:
If you have extreme performance problems the largest improvements you will get are by redesign not tweaking.


actually, thinking about it, i take that back. it's too ambiguous and vague, dogmatic and... just wrong.

[edited by - petewood on October 28, 2002 7:44:27 AM]
SabreMan
SabreMan
quote:
Original post by petewood
actually, thinking about it, i take that back. it''s too ambiguous and vague, dogmatic and... just wrong.

I thought it sounded reasonable.
Qw3r7yU10p!
Qw3r7yU10p!
well, it was a bit ambiguous and open to debate so i took it back.

the use of the phrase ''extreme performance problems'' just alone would have kept coming back to bite me if people chose to take it the wrong way. i can''t be bothered today (c:

someone might say, for example, an extreme performance problem could be improved by a factor of 100 times by making a different call to the graphics api.

i wouldn''t call that an extreme problem.

my emphasis is really on the ''problems'' part of the phrase. sometimes no matter of tweaking will give you the performance increase you need to be, and possibly even know to be, available.
civguy
civguy
I usually optimize code which I think will be a bottleneck in the final product, but I do this only for the rather low-level stuff. It''s pretty easy to calculate that the game will have 1000 monsters and each of them needs to call this routine 300 times/second, so the routine should be fast enough for that or I need a better algo. That way I won''t have any nasty surprises later on.

You shouldn''t really be too anal about the "optimization law". Having an educated guess about the potential bottlenecks is always a good thing IMO. Just don''t try to micro-optimize anything but the most potential bottlenecks until the product is almost ready. And then profile.
SabreMan
SabreMan
quote:
Original post by civguy
I usually optimize code which I think will be a bottleneck in the final product

But that''s precisely the basis of premature optimisation - you are spending time optimising something which you *think*, but do not *know*, will be a bottleneck. If there doesn''t turn out to be a bottleneck, you have wasted time and money. Humans are notoriously bad at predicting this kind of thing. You should always measure, and you shouldn''t even do that until there is an observable problem. The point I tried to make earlier is that you don''t have to wait for a completed application to be able to measure performance.
quote:

It''s pretty easy to calculate that the game will have 1000 monsters and each of them needs to call this routine 300 times/second, so the routine should be fast enough for that or I need a better algo.

But how do you know what "fast enough" means, or that another algorithm is "better" until you have measured your functionality using representative data.
quote:

Just don''t try to micro-optimize anything but the most potential bottlenecks until the product is almost ready. And then profile.

*All* optimisation activity should be *preceded* by profiling, else you don''t know what to optimise. Then you can follow it up with profiling to ensure the optimisations were good.
Ekas78
Ekas78
You didn''t plan you project good enough. Changing, say the pipe, requires alot of work..sure, but with good planning it should be possible. You can''t optimize a slow pipe into a fast one. I guess what you are describing is the lack of experience (not in a negative way). The fact that you say your project is "degrading" in speed suggest that you didn''t have your algos/architecture ready & analysed before you started to implement them. Planning is boooooooooring sure, but atleast you can minimize the number of ugly surprises during coding.
______Only dead fish go with the main-stream.
civguy
civguy
quote:
Original post by SabreMan
But how do you know what "fast enough" means, or that another algorithm is "better" until you have measured your functionality using representative data.
Hmm.. Ok, maybe it is profiling then. I usually make some test cases that try to mimic the real world situation, and see if they run fast enough.
quote:
The point I tried to make earlier is that you don''t have to wait for a completed application to be able to measure performance.
Actually, my point was pretty much the same but it came out wrong . But my way of doing it still involves the "educated guess" about how much some function will be used, and I know I can estimate that pretty well. To know whether the current function is fast enough or not, I naturally have to profile it with some test data.

Maybe it isn''t premature in a sense that I''d optimize before even testing it, but it''s premature in a sense that I don''t wait for the full product until profiling some modules/functions. Yea, that''s the source of confusion.
CWizard
CWizard
quote:
Original post by SabreMan
You have to remember that any time spent optimising is a complete waste of time and money until you know the thing you are optimising is going to cause a performance problem.
Why do you say that? Do you say that a newbie coding his first tertis clone that won''t get finished and noone else but him will play, is a waste of time? No, it''s learning and experience. Practising optimization is good when you have the opportunity, regardsless if the code is a bottleneck or not. If you only done optimization on real bottlenecks, you won''t do a good nor fast job when you really need to. Also, it doesn''t necessarily save time to wait with optimization, as it goes much faster to optimize a piece of code you just written, than doing it after a few month.


SabreMan
SabreMan
quote:
Original post by CWizard
Why do you say that? Do you say that a newbie coding his first tertis clone that won''t get finished and noone else but him will play, is a waste of time?

No, and neither have I said that. It would not be appropriate for a newbie coding his first tetris clone to engage in premature optimisation activity. Bear in mind its probably difficult enough for him to get the basic functionality right, quite possibly because he''s violated the first rule of optimisation by using an inappropriate language. I find it incredibly hard to imagine that our hypothetical newbie could code anything needing optimisation on his hypothetical PC.
quote:

If you only done optimization on real bottlenecks, you won''t do a good nor fast job when you really need to.

So when do you really need to optimize if it isn''t when you find a "real bottleneck"? When you find a pretend bottleneck perhaps?
quote:

Also, it doesn''t necessarily save time to wait with optimization, as it goes much faster to optimize a piece of code you just written, than doing it after a few month.

Wise programmers learn to how to minimise the probability of failure. If you wait until you are certain something needs optimising, then you are tipping the odds in your favour. Please explain why you think it doesn''t save time to wait until you are certain.
CWizard
CWizard
quote:
Original post by SabreMan
So when do you really need to optimize if it isn''t when you find a "real bottleneck"? When you find a pretend bottleneck perhaps?
Exactly my point. Unless we''re talking about pure professional projects, mostly all coders'' projects are "pretended". I do many projects beside professional (paying) ones, including optimizing them, because I like to code, and I can''t get enough experience. I''m not very good at Intel assembly, why I don''t mind spending a few hours doing asm optimization of whatever; that way I learn.

How would anyone learn to code, if they reasoned that they should wait untill they had something that "needed" to be coded, like you''re reasoning that one should never optimize before it''s "needed"?

I''d like to point out that I''m mostly talking about hobby coding, rather than professional. I would not dream of doing other than "casual" optimizing on a large (comercial) project.
nicho_tedja
nicho_tedja
sorry, but what is a profiler? is it a program that allows you to optimize your code? what does it do? how can i get it?

My compiler generates one error message: "does not compile."
My compiler generates one error message: "does not compile."

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.