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?
-
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
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.

- 39,201
- 12
- 97
- 154
-
-
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](http://www.gotw.ca/publications/concurrency-ddj.htm) 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 02:18
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.

- 3,168
- 14
- 17
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.

- 21,874
- 5
- 60
- 88
-
+1 great answer. The day computers begin to maintain code, ona can stop caring about readability. – Tulains Córdova Jul 10 '13 at 16:31
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.

- 198,589
- 55
- 464
- 673
-
-
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
-
Rarely do specifications cover everything and then developers have to be flexible. You can get all legalistic but then you have an unhappy customer. – CWallach Jul 10 '13 at 18:04