At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).
On the other hand, when I studied dynamic dispatch and stuff like that, I don't think enough people told me "when you do that, you are making this tradeoff".
I feel like it's worth sharing this kind of knowledge in order to make better informed decisions (possibly based on numbers). There's no need to become an extremist in either direction.
The claim of 20x program performance difference is overblown. Compilers can often remove virtual function calls, JITs can also do it at runtime. Virtual function calls in a tight loop are slow but most of your program isn't in a tight loop and few programs have compute as a bottleneck.
Measure your program, find the tight loops in your program and optimise that small part of your program.
Depends on the number of invocations of the program.
The “developer time is valuable” mantra is thrown left and right, disregarding how much of that valuable resource will be wasted down the line due to bad implementations.
If we optimize for developer time, let’s optimize across the software’s entire lifecycle, not just that first push of a MVP to production.
We just need to do away with shoddy first implementations, while avoiding premature optimization (or pointless perfectionism).
Which is all good in theory. In practice, management needs to also acquiesce and stop with the impossible deadlines.
I mean, I’ve worked on more than one projects that were sold to clients before they were implemented, and I think I’m not unique in that :)
This also presupposes that making a fast program is a lot more work. However poor performance is usually due to negligence rather than a lack of optimization effort. All you need to write reasonably fast code by default (without micro-optimizing) is:
1. a good knowledge of available algorithms 2. a good understanding of the problem
1. Is a one-time investment on the programmers part that benefits all future programs they write. There is no marginal cost to being familiar with what's available in <algorithm>. 2. Has a marginal cost, but it's probably a time saver anyway. Measure once, cut twice.
(This is not to endorse writing code that is harder than necessary to understand, or failing to document the parts that are necessarily hard.)