Seems like poor analysis on their part then. If they're leaving 3.5x perf on the floor, they're not spending their money very well.
We're working on applications that's either waiting for the disk, waiting for the db, waiting for some http server or waiting for the user.
None of our customers will notice the difference if my button click event handler takes 50ms instead of 10ms, or if the integration service that processes a few dozen files per day spends 5 seconds instead of 1 second.
I'll easily trade 5x performance in 99% of my code if it makes me produce 5x more features, because most of the time my code runs in just a few milliseconds at a time anyway.
Of course, I'm weary of big-Oh, that one will bit ya. But a mere 3.5x is almost never worth chasing for us.
> At Netflix, we periodically reevaluate our workloads to optimize utilization of available capacity.
The idea being that if you pay for fewer servers you spend less money
If you try to be good at waiting on many things, you can use one machine instead of a hundred
> None of our customers will notice the difference if my button click event handler takes 50ms instead of 10ms
They absolutely will, what
We can't run on one, because customers run our application on-prem.
> They absolutely will, what
How can you be so sure?
Sure, 10ms vs 40ms is measurable, and for the keen-eyed noticeable. But if you're only pressing the button once every 5 minutes, it doesn't matter. Similarly, if the button triggers an asynchronous call to a third-party webservice that takes seconds to respond, it doesn't matter. And so on.
Of course, for the things where users are affected by low latency, we try to take care. But overall that's a very, very small portion out of our full functionality.
It's a great tool with a low learning curve that just requires SSH.