Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If you have to pay the price of performance to make code more readable would you prefer that or you would always prefer performance over it?

share|improve this question

closed as primarily opinion-based by MichaelT, Robert Harvey, user16764, GlenH7, JeffO Jul 10 '13 at 16:53

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
I understand that it will not have a definite answer ,but based on your experience I wanted to understand which one have you given more priority at times and why –  prasun Jul 10 '13 at 16:15
    
Obviously, the answer is: "it depends." A performance difference of seconds is quite different from a performance difference of milliseconds –  user16764 Jul 10 '13 at 16:16
    
Could you provide an example? –  JeffO Jul 10 '13 at 16:53

4 Answers 4

up vote 10 down vote accepted

In layman's words:

  • Making the code ugly does not make it fast.
  • Making the code clean does not make it slow (or fast).
  • Making the code ugly does make the maintainer's work slower.
  • Clean code usually means the code was made by someone who cares.
  • One who cares to make his code clean, usually cares to make it efficient.
  • Hardware becomes cheaper with time.
  • Programmers don't get cheaper over time.
  • CPU time is cheaper than programmer's time.
  • Some performance problems can be solved by throwing money at them.
  • Very few code maintainability problems can be solved by throwing money at them.
share|improve this answer
    
who has time for perfection? –  JeffO Jul 10 '13 at 16:52
    
Add Amdahl's law to the list (and connecting all the dots together) will make it the software equivalent of Moore's law. –  rwong Jul 10 '13 at 16:58
    
See Herb Sutter's The Free Lunch is Over on reasons why performance problems can't be solved by hardware. Also, someone posted a diagram a while ago which says most people's code started with neither clean nor fast. –  rwong Jul 11 '13 at 2:18

The general idea is to make the code as readable as possible first, and then only look at optimizing where there's a proven performance problem. In most cases a response time of, e.g. 5 ms instead of 1 ms isn't going to make a difference. 50 seconds instead of 10 seconds is a different matter.

share|improve this answer
    
+1 great answer. The day computers begin to maintain code, ona can stop caring about readability. –  user61852 Jul 10 '13 at 16:31

You should always choose clean code first as it reduces the cost of maintenance and it likely to be less complex. You shouldn't address a performance problem that you haven't identified; that's probably a premature optimisation.

See When is Optimization Premature?

share|improve this answer

Prefer meeting your customer's requirements.

If the customer has imposed a performance requirement, and that requirement dictates that you change the code to make it less readable but more performant, then you change the code to make it less readable but more performant.

But ugly fast code is a false dichotomy. Sometimes you can make code perform better without making it significantly more ugly.

If the code already performs adequately, then prefer readability over more performance.

Measure first, then optimize the slow bits only if you need to do so to meet the requirements.

share|improve this answer
    
"But ugly fast code is a false dichotomy." Yep. –  user16764 Jul 10 '13 at 16:32
    
Often the customer will expect a satisfactory level of performance without having a written requirement. The developer should clarify this. –  CWallach Jul 10 '13 at 16:37
2  
@CWallach: That's not a requirement, it's a wish. A requirement is stated explicitly, like: "All web pages shall render in 1000ms or less, under a single-user load." –  Robert Harvey Jul 10 '13 at 16:39
    
None the less, when a web page renders too slowly the customer will consider it a bug and expect the developer to fix it. –  CWallach Jul 10 '13 at 17:09
1  
@CWallach: Not if the page meets the stated customer specification. There either needs to be an amendment to the specification, or a waiver if it is discovered that making a particular page compliant will be too expensive. "Too slow" is not measurable. –  Robert Harvey Jul 10 '13 at 17:12

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