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?
3
-
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– prasunJul 10, 2013 at 16:15
-
Obviously, the answer is: "it depends." A performance difference of seconds is quite different from a performance difference of milliseconds– user16764Jul 10, 2013 at 16:16
-
Could you provide an example?– JeffOJul 10, 2013 at 16:53
Add a comment
|
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.
answered Jul 10, 2013 at 16:13
-
-
Add Amdahl's law to the list (and connecting all the dots together) will make it the software equivalent of Moore's law.– rwongJul 10, 2013 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.– rwongJul 11, 2013 at 2: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.
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.
answered Jul 10, 2013 at 16:11
-
+1 great answer. The day computers begin to maintain code, ona can stop caring about readability. Jul 10, 2013 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.
answered Jul 10, 2013 at 16:15
-
-
Often the customer will expect a satisfactory level of performance without having a written requirement. The developer should clarify this.– CWallachJul 10, 2013 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." Jul 10, 2013 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.– CWallachJul 10, 2013 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. Jul 10, 2013 at 17:12