4 ms·

Ironically, this article sets up a strawman of people who claim performance NEVER matters, and then rants long windedly in a tone suggesting it always matters.

Ironically, this article sets up a strawman of people who claim performance NEVER matters, and then rants long windedly in a tone suggesting it always matters. My general principle: don’t give uni-directional advice when optimizing a u-shaped loss function. I usually find that those failing to advocate the nuanced position “you can spend too much AND too little time on perf, here is how to prioritize” are not adding useful information to the conversation. The truth is, most startups don’t need to worry much about perf. It’s a feature that your customers don’t usually ask for at first. At the other end of the scale, giant companies invest huge sums in taming performance. And your own situation will have more parameters than just that one simplified spectrum. Measure ROI honestly, and prioritize accordingly!

Hikikomori 4y ago
He isn't saying that you should spend time on optimising your code, rather that you should write performant code from the beginning by not giving the cpu more work than it needs to do to perform the task, typically by avoiding OO paradigms, followings things like SOLID, etc. Then if needed, real optimisation can handle the hotspots in your code and is typically something that only a few of an orgs best engineers can do properly, but if everything is slow then its an insurmountable task for these few engineers. If you want to understand what he means with this watch the refterm series. https://www.youtube.com/watch?v=pgoetgxecw8 https://www.youtube.com/watch?v=pgoetgxecw8
gizmo 4y ago
The issue is that there is no need for software to be incredibly slow by default. This used not to be the case. Back in the day you just wrote straightforward code in C (or C++) and you got good performance for free. It makes sense that people want to use a programming language that allows for rapid prototyping if they want to get V1 out of the door. That's fine. But that doesn't explain why languages like Python and Ruby are incredibly slow in the first place. These are 20 year old languages that people have invested a ton of effort into. And despite a full decade of trying to make the languages faster they're still slow to point of near unusability. These languages, along with PHP and Javascript, were designed by people who paid zero attention to the performance consequences of the design decisions they made. Today, after industry having spend untold billions (yes, with a B) on trying to get the performance to an acceptable level getting anything written in these interpreted languages to run at an acceptable speed is painful. We are collectively wasting untold hours because our programming environments are bad, the languages are bad, the libraries we use are bad, and the standards are bad. This is not to say it's all hopeless, but we could be doing a lot better if we didn't focus so much on "moving fast and breaking things" and pursued quality instead.
ehaliewicz2 4y ago
Casey does say that almost always you don't need to "optimize", but rather just need to think about the execution of your code on hardware. This video isn't quite as nuanced, but he does talk about this in other ones.
Tomis02 4y ago
> this article sets up a strawman of people who claim performance NEVER matters That's just ONE out of the five excuses he mentioned. And just because you haven't met people who claim performance never matters doesn't mean they don't exist. > Yadda yadda You're basically agreeing with Casey but make it sound as if he's saying the opposite from what you're saying.

Hikikomori 4y ago

He isn't saying that you should spend time on optimising your code, rather that you should write performant code from the beginning by not giving the cpu more work than it needs to do to perform the task, typically by avoiding OO paradigms, followings things like SOLID, etc. Then if needed, real optimisation can handle the hotspots in your code and is typically something that only a few of an orgs best engineers can do properly, but if everything is slow then its an insurmountable task for these few engineers. If you want to understand what he means with this watch the refterm series. https://www.youtube.com/watch?v=pgoetgxecw8 https://www.youtube.com/watch?v=pgoetgxecw8

gizmo 4y ago

The issue is that there is no need for software to be incredibly slow by default. This used not to be the case. Back in the day you just wrote straightforward code in C (or C++) and you got good performance for free. It makes sense that people want to use a programming language that allows for rapid prototyping if they want to get V1 out of the door. That's fine. But that doesn't explain why languages like Python and Ruby are incredibly slow in the first place. These are 20 year old languages that people have invested a ton of effort into. And despite a full decade of trying to make the languages faster they're still slow to point of near unusability. These languages, along with PHP and Javascript, were designed by people who paid zero attention to the performance consequences of the design decisions they made. Today, after industry having spend untold billions (yes, with a B) on trying to get the performance to an acceptable level getting anything written in these interpreted languages to run at an acceptable speed is painful. We are collectively wasting untold hours because our programming environments are bad, the languages are bad, the libraries we use are bad, and the standards are bad. This is not to say it's all hopeless, but we could be doing a lot better if we didn't focus so much on "moving fast and breaking things" and pursued quality instead.

ehaliewicz2 4y ago

Casey does say that almost always you don't need to "optimize", but rather just need to think about the execution of your code on hardware. This video isn't quite as nuanced, but he does talk about this in other ones.

Tomis02 4y ago

> this article sets up a strawman of people who claim performance NEVER matters That's just ONE out of the five excuses he mentioned. And just because you haven't met people who claim performance never matters doesn't mean they don't exist. > Yadda yadda You're basically agreeing with Casey but make it sound as if he's saying the opposite from what you're saying.