1

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.

Florian Margaine
  • 6,791
  • 3
  • 33
  • 46
saadlulu
  • 121
  • 5
  • It really depends on what you call "write optimized". Do you mean "find a way to do only one SQL request instead of 100", or "find a way to loop twice instead of thrice"? – Florian Margaine May 07 '13 at 08:41
  • One SQL that replaces the 100 requests. thats what I mean – saadlulu May 07 '13 at 08:44
  • 1
    possible duplicate of [When is optimization not premature and therefore not evil?](http://programmers.stackexchange.com/questions/33020/when-is-optimization-not-premature-and-therefore-not-evil) and of [Is micro-optimisation important when coding?](http://programmers.stackexchange.com/questions/99445/is-micro-optimisation-important-when-coding) – gnat May 07 '13 at 08:49
  • Write code which is easy to optimise. E.g., write a code in a high level DSL and then keep it clean and readable and optimise the DSL compiler instead of the source code. – SK-logic May 07 '13 at 09:00

4 Answers4

17

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.
Joris Timmermans
  • 8,998
  • 2
  • 36
  • 60
  • 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 07 '13 at 08: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 07 '13 at 09:04
  • I really like this answer, it says it all so well. – Florian Margaine May 07 '13 at 09: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. – Bart van Ingen Schenau May 07 '13 at 09:09
  • 1
    I learned these rules as "make it work, make it right, then make it fast". – cHao May 08 '13 at 14:23
10

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:

Community
  • 1
Florian Margaine
  • 6,791
  • 3
  • 33
  • 46
2

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.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 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 07 '13 at 08: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. – Arseni Mourzenko May 07 '13 at 09:28
0

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

Max Lanovoy
  • 11