5

Is it a good practice to follow optimization techniques during initial coding itself or should one concentrate purely on realization of functionality first?

If one concentrates purely on functionality during initial coding, then how easy or difficult is it to take care of optimization later on?

Jay
  • 24,173
  • 25
  • 93
  • 141
  • Similar question (not actually a duplicate): http://stackoverflow.com/questions/895574/what-are-some-good-code-optimization-methods – TRiG Jan 19 '10 at 10:02

8 Answers8

16

Optimise your design and architecture - don't lock yourself into a design which will never scale - but don't micro-optimise your implementation. In particular, don't sacrifice simplicity and readability for micro-optimised implementation... at least not without benchmarking your code (ideally your whole system) first.

Measurement really is the key point when it comes to performance. Bottlenecks are almost never where you expect them to be. There are loads of different ways of measuring; optimisation without any measurement is futile IMO.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 3
    +1 for not just quoting Knuth. If I see that quote once more I might go crazy ;) – Dominic Rodger Jan 19 '10 at 09:59
  • 1
    @Dominic Rodger This one http://stackoverflow.com/questions/2092562/is-it-a-good-practice-to-do-optimization-during-initial-coding/2092576#2092576 ? :) – jensgram Jan 19 '10 at 10:00
2

Donald Knuth said:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

miku
  • 181,842
  • 47
  • 306
  • 310
1

It depends what you see as "optimization". Micro-optimization should not be done in early stages, and afterwards only if you have a valid reason to do so (e.g. profiler results or similar).

However, writing well-structured, clean code following best practices and common coding guidelines is a good habit, and once you're used to it, it doesn't take much more time than writing sloppy code. This kind of "optimization" (not the correct word for it, but some see it as such) should be done from the beginning.

Lucero
  • 59,176
  • 9
  • 122
  • 152
0

See http://en.wikipedia.org/wiki/Program_optimization for quotes by Knuth.

If you believe that optimization might make your code harder to (a) get right in the first place, or (b) maintain in the long run, then it's probably best to get it right first. Having good development processes, such as Test Driven Development, can help you make optimisations later.

It's always better to have it work right and slow, than wrong and fast.

John
  • 6,701
  • 3
  • 34
  • 56
0

Rightly said by Donald Knuth "Premature optimization is the the root of all evil " , and it makes your coding speed slow. The best way to optimize is by visiting the codebase again and refactoring. This way you know which part of the code is often used or is a bottleneck and should be fine tuned.

shikhar
  • 2,431
  • 2
  • 19
  • 29
0

Premature optimization is not a good thing. And that goes especially for low level optimization. But at a higher level your design shouldn't lock out any future optimization.

For example.

The retrieval of collections should be hidden behind methods call, in the end you can always decide to cache the retrieval of collections or not. After you have a stable application and(!) you have developed regression unit tests. You can profile the application and optimize the hotspots. And remember to after every optimalization step you should run your complete unit test set.

Waverick
  • 1,984
  • 1
  • 11
  • 16
0

Is it a good practice to follow optimization techniques during initial coding itself or should one concentrate purely on realization of functionality first?

If you know performance is critical (or important), consider it in your design and write it correctly the first time. If you don't also consider this in your design and it is important, you are wasting time or "developing a proof of concept".

Part of this comes down to experience; If you know optimizations and your program's problem areas or have already implemented similar functionalities in the past, your experience will certainly help you create an implementation closer to the end result the first time. If you still need a proof of concept, you should not be writing the actual program until that's completed -- kick out some tests to determine what solution is appropriate for the problem, then implement it properly.

If one concentrates purely on functionality during initial coding, then how easy or difficult is it to take care of optimization later on?

Some fixes are quick, others deserve complete rewrites. The more that needs to change and adapt after the fact, the more time you waste re-testing and maintaining a poorly implemented program. The libraries that are easiest to maintain and sustain the demands are typically the ones which the engineer had an understanding of what design is ideal, and strived to meet that ideal during initial implementation.

Of course, that also assumes you favor a long-lived program!

justin
  • 104,054
  • 14
  • 179
  • 226
-1

Premature optimization is the the root of all evil

To elaborate more on this famous quote, doing optimization early has the disadvantage of distracting you from doing a good design. Also, programmers are notoriously bad in finding which parts of the code cause the more trouble, and so try hard to optimize things that aren't that important. You should always measure first to find out what needs to be optimized and this can only happen in later phases.

kgiannakakis
  • 103,016
  • 27
  • 158
  • 194
  • 1
    Corollary: the aforementioned isn't meant to endorse *shoddy, unacceptably slow*, designs – ZJR Jan 19 '10 at 09:58