On Optimisation

This is not about any one optimisation approach but about my overall strategy. It might answer some questions readers have, or at least address concerns I've seen raised elsewhere.


Often when discussing optimisation techniques someone will state that it is all a waste of time. That optimisations such as this and this are pointless as they produce no measurable benefit. Or if they do it is better to write your code then use a profiler to find the hotspots and optimise them, not waste time optimising code that will make no difference.


On whether an optimisation is measurable, individually they make little difference but across a whole game they can provide a significant boost. I agree a little with the last point. Much code that I've written such as my level bitmap parsing code is not at all fast, though it doesn't need to be as it runs only once at startup (or not at all as that code was replaced with something better).


A lot of code is like that, or should be. If you have expensive asset loading, background generation or AI pathfinding code do as much as you can at startup or level start. Or store effects and data in the .swf rather than generate them at runtime.


But most games have code where performance matters, sometimes a lot of it. And very often it matters in a particular way: it is this code that determines how fast and smoothly the game runs, and on some machines it makes the difference between the game running well or not. It shouldn't just run acceptably fast as on some platforms, but as fast as possible so the game scales well across a wide range of platforms.


Why not optimise later? Three reasons:

• Why write code two or more times when you can just write it once?
• If you don't know how to optimise as you write how will you know how to do it later?
• You may optimise the wrong thing.

The first I think is obvious: writing efficient code the first time, even if it takes a little longer to plan, saves time in the long run and lets you focus on other things. The second means that if you didn't know you were writing slow code how will you recognise it when a profiler (or, worse, an end-user) tells you it's slow?

The third is I think is the biggest issue: if your code is too slow you may end up with a much poorer game as you limit game complexity, the number of enemies, the number of filters or sounds. Some games run slowly for no obvious reason then use the quality setting to get back some performance, presenting the user with a choice between a poor frame rate and compromised graphics quality.