3 ms·

I’ve never seen anyone make the argument that performance is not important. I have seen people make the argument that performance is less imprtant than some oth

by tomgp 3y ago

I’ve never seen anyone make the argument that performance is not important. I have seen people make the argument that performance is less imprtant than some other property (maintainability, extensibility, legibility etc. etc.) given certain aims and constraints.

kjksf 3y ago
Everything cannot be important. If you say that maintainability, extensibility, legibility etc. etc. is more important than performance then you are, in fact, saying that performance is NOT important. But those are mostly just the excuses that Casey is ranting about. There's nothing inherent in writing fast code that makes is not maintainable, not extensible, not legible not etc., not etc. In fact, the things that make code less maintainable and less legible are often the things that make is slower. Things like replacing new Foo() with FooFactory and replacing FooFactory with FooFactoryProvider and then encoding logic in XML files. Those are things that people do way more often that writing SIMD intrinsic. And there are those who way overemphasize supposed "legibility" over performance. In JavaScript land you get legion claiming that the world will end if they rewrite unnecessarily slow map(), filter(), forEach() etc. with a regular for loop.
AbsoluteCabbage 3y ago
That's literally one of the excuses he debunks. Case in point: it is such a large factor on customer satisfaction and the bottom line that large companies such as Facebook would spend significant sums of time and money improving performance.
- tomgp 3y ago
  Yes, clearly in that case performance is important but is performance always the most important thing? I read the article and didn't find it convincing, I would argue that it's clearly not always the most important thing. This isn't an "excuse" it's a calculation that teams make, the author feels that people make the tradeoff at the wrong point but instead of making that argument he frames decisions not to prioritise performance as "excuses" which is bullshit. There's always more performance optimisations one can make and there always comes a point where it just doesn't make sense to do so for all manner of reasons. A trivial example: I have a script which downloads a few thousand GIS Shape files and converts them into geoJSON. It runs automatically once a month, usually whilst I sleep. A run takes about 5 minutes at the moment but there are a couple of things I could do to make it run in a fraction of that time but then the script would be two or three times longer and more complex, and I'd have to spend a couple of hours writing and testing code, (there'd also be some edge cases that I'd need to account for which the current setup allows me to ignore). I judge that to be a waste of time which would make anyone who has to take ownership of this script in the future's life more difficult. So that's my "excuse" and I'm sticking to it.
- cratermoon 3y ago
  Except he hasn't debunked anything. He's pointed out the specific niches where performance matters and one of the 5 "excuses" he raises is countered. Some software counters some of the "excuses" some of the time. Not all software counters all of the "excuses" all of the time. If anything, the article points out the accuracy and value. of the five metrics for evaluating performance needs over other business needs.

by tomgp 3y ago

kjksf 3y ago

Everything cannot be important. If you say that maintainability, extensibility, legibility etc. etc. is more important than performance then you are, in fact, saying that performance is NOT important. But those are mostly just the excuses that Casey is ranting about. There's nothing inherent in writing fast code that makes is not maintainable, not extensible, not legible not etc., not etc. In fact, the things that make code less maintainable and less legible are often the things that make is slower. Things like replacing new Foo() with FooFactory and replacing FooFactory with FooFactoryProvider and then encoding logic in XML files. Those are things that people do way more often that writing SIMD intrinsic. And there are those who way overemphasize supposed "legibility" over performance. In JavaScript land you get legion claiming that the world will end if they rewrite unnecessarily slow map(), filter(), forEach() etc. with a regular for loop.

AbsoluteCabbage 3y ago

That's literally one of the excuses he debunks. Case in point: it is such a large factor on customer satisfaction and the bottom line that large companies such as Facebook would spend significant sums of time and money improving performance.

tomgp 3y ago
Yes, clearly in that case performance is important but is performance always the most important thing? I read the article and didn't find it convincing, I would argue that it's clearly not always the most important thing. This isn't an "excuse" it's a calculation that teams make, the author feels that people make the tradeoff at the wrong point but instead of making that argument he frames decisions not to prioritise performance as "excuses" which is bullshit. There's always more performance optimisations one can make and there always comes a point where it just doesn't make sense to do so for all manner of reasons. A trivial example: I have a script which downloads a few thousand GIS Shape files and converts them into geoJSON. It runs automatically once a month, usually whilst I sleep. A run takes about 5 minutes at the moment but there are a couple of things I could do to make it run in a fraction of that time but then the script would be two or three times longer and more complex, and I'd have to spend a couple of hours writing and testing code, (there'd also be some edge cases that I'd need to account for which the current setup allows me to ignore). I judge that to be a waste of time which would make anyone who has to take ownership of this script in the future's life more difficult. So that's my "excuse" and I'm sticking to it.
cratermoon 3y ago
Except he hasn't debunked anything. He's pointed out the specific niches where performance matters and one of the 5 "excuses" he raises is countered. Some software counters some of the "excuses" some of the time. Not all software counters all of the "excuses" all of the time. If anything, the article points out the accuracy and value. of the five metrics for evaluating performance needs over other business needs.