4 ms·
> This phrase has been taken as justification for writing inefficient code, understanding it as "performance doesn't matter [for what we do]". There is no cont
by ReleaseCandidat 3y ago
> This phrase has been taken as justification for writing inefficient code, understanding it as "performance doesn't matter [for what we do]".
There is no contradiction. Writing inefficient code is perfectly fine until you _know_ (this means you have measurements that show that) it is _too_ inefficient and has to be optimised.
How do you measure the "optimisation" without "inefficient code" as baseline to begin with?
- edflsafoiewq 3y agoIn that case, how do you know you're measuring the "optimization" and not "how awful the original code was"?
- jraph 3y ago> Writing inefficient code is perfectly fine until you _know_ (this means you have measurements that show that) it is _too_ inefficient and has to be optimised. What about inefficient code only if you _know_ that it does not matter? I'm not talking about optimizing. I'm talking about avoiding inefficiencies in the first place. This is what I'm talking about: we are in "inefficient by default" mode. That leads to requiring powerful hardware to display the most lambda websites.
- vlovich123 3y agoDepends what you mean by inefficient. The other thing Knuth meant is that you should focus your efficiency energy first on overall design efficiency. Algorithmic and other efficiencies are irrelevant if your design is bad and a bad design cannot be fixed by looking at the profiler and fixing hotspots