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
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.
3
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?
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.
1
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.
6