Write then optimise or write optimised [duplicate]

Question

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.

Answer 1

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.

Answer 2

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:

• Is it always wrong to optimize before profiling?
• Is micro-optimisation important when coding?

Answer 3

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.

Answer 4

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