With a non-pessimal design, not only you are able to pay less money on servers in the long term, you're also able to delay complex scaling strategies. Scaling also costs money.
Not to mention that building something with this kind of overhead also means that a lot developer time was spent in the first place, which is still expensive in our industry.
>Virtually every distributed service built today is able to take advantage of this
most of built today services can take much more advantage in using better system design practices.
If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless [..] Notice that the above definition most emphatically does not say anything about making the software as fast as possible".[0]
[0] https://www.jagregory.com/abrash-black-book/#understanding-h...
No, though s/any/many/ would make this true.
There are no hotspots. Computing has become lukewarm by default, and just like the globe, it's slowly heating up.
What problems do they prevent?
If you're able to make a program into a sort of puzzle concealing its state inside a twisty maze of tiny virtual functions so it's impossible to see plainly how anything is done, then you become indispensable as the only one who's internalized how the thing works.
And then you insist it's all for easier comprehension… for those sufficiently intelligent to comprehend it.
No it wont say something like that but if you profile Python itself and see that a lot of time is spent in Python you can get a hint that rewriting it in another language that doesn't have Python's overhead might help.
But you can only judge that for the very limited set of hardware you personally have access to. You might have many users -- or potential users -- with slower CPUs.
(ignoring projects made for fun of course)
Of course it will.
If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.
Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.
Boom. You're operating close to the speed of light.
but you are actually talking about optimizing system design, and not reducing virtual functions calls :).
And that the point of this thread: you need to optimize parts that slow you the most.
So no, in most cases optimizing virtual calls won't bring you from 1s to 30ms
As an example, I recently worked on a large system that was optimized to do a big data transformation in an efficient way. It turns out that data is transformed back to the original format later downstream. So much for the optimization...
All that is to say, often it is the case that "simple > fast"
Clean code at the time had a lot going forward it, and it was an improvement over a lot of JavaEE code that was written in absolutely procedural ways with less care for the developer reading the classes, functions, or individual statements compared to punching out near assembly-like code and moving on.
On slower languages with slower runtimes, something that is 10x slower than normal code will have much more overhead than in the examples demonstrated by Casey. It won't be about "30ms vs 25ms" as some people are saying. In the past I remember seeing differences between 400ms and 20ms between JBuilder and .to_json in a critical endpoint in a Rails app, to give one example. Sure, one is "cleaner", but in the end it's a 20x overhead that has no place this case.
Also, the myth that "processors spend time waiting for IO" that is spread across this thread is BS. In reality, that's only true for single-user programs. If the app is part of a distributed system, the CPU time can be used to serve more users. This allows you to significantly delay more complex scalability efforts, which is also precious developer (or DevOps) time.
Not to mention that applying "Clean Code" in the first place also takes precious time, which could be used for features or anything making money, even optimizing the DB. Instead, this time is used to mess up the code in ways that have zero proven efficacy, and some developers instead think are terrible.
If you're working with databases, performance often boils down to minimizing the number of times you have to access the database (over a multi-service stack, not just a single web service).
When you hit Amdahl's law, it's because you (or someone else) has made decisions about the high level design/patterns to use in a system. To remove such bottlenecks, you may have to scrap the entire project and start over.
For the inner loops, it's perfectly fine to leave most of the optimization for later. But for overall design, it needs to be right from the start.
Time and time again, I see devs stuck in some paradigm (often front-end devs or low volumen RESTful microservices) that makes it almost impossible to handle non-trival data volumes or traffic, causing new products to fail.
I do agree that overall design needs to fit performance requirements but for the most part that has nothing to do with "clean code" patterns.