A common programming quote I see every day is:

Premature optimization is the root of all evil!

I admit I'm one of those guys that like to do premature optimization in a pretty obssessive manner but that's probably because I'm not aware how powerful modern processors are. I can think of lots of sollutions for a problem, but all of them are tough on the memory side, and I keep thinking "This will hurt me more in the future when I'll have to re-do it because it's bad performance-wise."

How do you know when the code you are thinking of is going too far and is not a case of premature optimization? How much can your game handle at a time before performance becomes a problem?

  • \$\begingroup\$ I think it fits GDSE as well as or worse than programmers.SE. \$\endgroup\$ Oct 20, 2012 at 12:49

3 Answers 3


Simple, when it runs slowly. (Or consumes a lot of memory.)

Premature Optimization is optimizing things without reason, e.g. before you run into any problems because of the performance. For example when you optimize your path-finding algorithm just because it can be faster, not because you noticed that your path-finding takes up a too large part of your CPU time.

That's just bad because optimization is a trade off, when you code you should code for maximum readability and maintainability, not for tiny performance benefits. Highly optimized code is usually hard to understand and thus hard to maintain.

Make a goal what kind of hardware you want to support and test your game on that hardware. Does it run at full speed? Then it's okay, keep on coding. If not profile it, check what parts are making it slow and optimize those parts.

  • 2
    \$\begingroup\$ I'm not so sure if optimized code is always less readable. \$\endgroup\$ Oct 20, 2012 at 12:44
  • 3
    \$\begingroup\$ Well, if you aim for maximum readability the time you write the code it is. Because any changes which don't aim at that same goal will differ from it. \$\endgroup\$
    – API-Beast
    Oct 20, 2012 at 12:50
  • 1
    \$\begingroup\$ In a good design, optimisation can be done later. Speed is a feature, but features are meaningless if you never get done. Put that effort into a good system design rather than optimisation, and then when you have something that works you can start making it work fast. \$\endgroup\$
    – Phoshi
    Oct 20, 2012 at 18:08

Think of optimization on your designing stage, when you consider if the general algorithm (it's outline) is fast enough for your game, or maybe it may be too slow for a smooth FPS. If you're not sure, do a quick, dirty test (if possible).

Then, forget about optimizing on first stage of programming. Optimizing here is not necessarily bad, but may decrease readability of the code or prove to be useless if at the end of this stage your prototype will show the design is wrong.

After making a working prototype, try to isolate parts of code like functions or classes and test them with unit tests.

Only then optimize final, tested (and working) functions/classes, and then test them again using same unit tests.

You will need a common sense to decide which function is CPU heavy (you can also measure it, but usually it should be obvious). Spend most time optimizing code that takes most time to execute (counting it's repetition).


When choosing whether or not to spend time on optimizing something, the most important factor is how often this code is executed:

  • Occasionally, maybe once every few minutes: Why bother?
  • Once per frame: Might be worth it.
  • Once per frame and game object: Should be optimized
  • For every pixel painted: Stop cutting corners - you must make that faster!

Special consideration should be taken for code which is executed in situations which are especially important for the user experience. Mainly loading times and saving times.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .