Do you write your code then optimise it? Or do you write an optimised code from the beginning.

I always believe in writing optimised since I really dont like to rewrite code, But please share your thoughts.


4 Answers 4


There's a simple order rule of three:

  1. Get it right. Correctness is paramount, something that does the wrong thing fast or beautifully is useless. This has to go deeper than "oh this seems to work okay" - it has to really work reliably for the entire domain of application that you are intending to use the code for.
  2. Get it nice. Elegance and simplicity of code is important. The code you wrote under 1 is likely to have several prototype-like properties. In this stage you may be able to reduce the amount of code from 1 drastically, make it a lot simpler, or both. Having easy-to-understand, well-documented, elegant code makes it easier to move to the next step. What often also happens here is that you may spot an algorithmic optimization to solve the same problem just as correctly. These algorithmic optimizations are usually much cleaner, better and more effective than very low-level to-the-metal optimizations.
  3. Get it fast. Now that you know that it works, and how it works and it's well-documented, you have a look to see if you need to make it faster. Usually you won't - see Florian's answer below. Only if you absolutely do need to optimize (use a profiler!), you do that now. You're starting from beautiful well-documented code. You're likely to end up with much less beautiful arcane code if you're really optimizing hard - but that's okay, it's documented, and you have the beautiful version in your VCS history to refer back to as well.
  • thats the problem right there in my opinion, Get it fast is the last on the list, while it may actually get you to rewrite your whole code. meaning you have to loop through your list multiple times instead of just once.
    – saadlulu
    May 7, 2013 at 8:59
  • 5
    @saadlulu if getting it fast requires one to rewrite whole code, this typically means "get it nice" part has failed. 80% time is spent in 20% code, good design would have it separated and thus wouldn't need such a rewrite
    – gnat
    May 7, 2013 at 9:04
  • I really like this answer, it says it all so well. May 7, 2013 at 9:07
  • 3
    @saadlulu: If you don't start with deliberately slow code, in 9 out of 10 cases you will be done after step 2. Unless of course you mean by optimisation, using the language's sort routine instead of writing your own bogosort. In that case, go right ahead with writing optimised code. May 7, 2013 at 9:09
  • 1
    I learned these rules as "make it work, make it right, then make it fast".
    – cHao
    May 8, 2013 at 14:23

The rule of thumb is this one (emphasis mine):

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

-- Donald E. Knuth, "Structured Programming with go to Statements"

Now, this doesn't mean you should write inefficient code. You should write efficient code if it doesn't take much more time than inefficient code. If you can do 1 SQL request instead of 100, please do so. If it doesn't take you much more time, that is.

This code might not be used very often, so it's actually not a bottleneck at all, even though it might seem inefficient. If writing it in an efficient way means spending too much time, there is no added-value to your business.

Then of course, if you have to optimize something because it's slow, never forget to profile first.

Some links that might interest you:

  • 2
    +1 for Knuth. But one should cite one's quotes. May 7, 2013 at 10:40

Are you suggesting to do premature optimization?

The code is fast when it matches the performance non-functional requirements. Until those requirements are fulfilled, you don't have to care about performance: there are much more important things to care about, like the quality of your code, the architecture, etc.

Once the non-functional performance requirement is broken by your code, it means that it's slower than what is acceptable/desirable. At this point, you should:

  • Profile your code (instead of guessing where the bottleneck is, since we always get it wrong),

  • Optimize it until the test corresponding to the requirement passes again.

  • So basically you are saying that I should go with the requirements and care less about the optimisation, but once im done I should revisit the code and give it a hair cut?
    – saadlulu
    May 7, 2013 at 8:54
  • 1
    You optimize when you know where the problem is located. You know that by profiling your code, not by randomly guessing. You feel the need to profile your code when a performance test starts to fail. May 7, 2013 at 9:28

Write optimized when you know for sure that it will have an effect and is justified in the mean of code readability.


Not the answer you're looking for? Browse other questions tagged or ask your own question.