Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance excuses debunked

computerenhance.com

Post reply on HN
Print view View original

121–130 of 130 posts

Re: Performance excuses debunked

#121

Post by db48x »

jiggawatts wrote: post #16
db48x wrote: post #8

Earlier quoted context omitted.

I know what you mean; I’ve made a lot of money by cleaning up other people’s messes. Still, I’m pretty sure I’d prefer a world where software was just better overall and there were fewer messes.

I had a two year stint where I ran around doing "database optimisation" projects that were a week of billable time at consulting rates, and my entire "toolkit" was to simply flip three boolean flags from bad to good values. Now in the public cloud my gimmick is to switch VMs over to current-generation AMD EPYC models, and then collect my pay-check for the "performance tuning". The fruit is hanging so low that I'm tra…

My favorite is to raise the Postgres work_mem value until their queries stop using disk buffers.

Re: Performance excuses debunked

#122

Post by brhsagain »

robby_w_g wrote: post #98
li4ick wrote: post #87

You know, reading these comments is absolutely hilarious. It's because of this and that, hundreds of excuses that dance around the simple truth: you're an incompetent programmer. That's it. No, you're not capable of making something twice as fast if only you cared or had the time. If you haven't done it as a constant exercise, you can't.

> It's because of this and that, hundreds of excuses that dance around the simple truth: you're an incompetent programmer. Classic arrogance and naivety from a Casey follower. Name call all you want, you can't hand wave the reality that the business determines the requirements, and in my industry they don't care about performance until it's a noticeable problem. Oh and the requirements they gave you are solving probl…

I don't think the structure of the "business requirements" argument is correct, and I will try to explain why.

To a first approximation, the reason modern software is slow isn't due to failure to optimize this algorithm or that code path, but rather the entire pancake stack of slow defaults — frameworks, runtimes, architectures, design patterns, etc. — where, before you even sit down and write a line of "business logic" code, or code that does something, you're already living inside a slow framework written in a slow language on top of a slow runtime inside a container with a server-client architecture where every RPC call is a JSON blob POSTed over HTTP or something. This is considered industry standard.

The "business requirements" guy is basically saying, I have to ship this thing by friday, I'm just going to pick the industry standard tools that let me write a few lines of code to do the thing I need to do. Ok, but that's the tradeoff he's making. He's deciding to pick up extremely slow tools for the sake of meeting his immediate deadline. That decision is producing unacceptable results.

It's not enough just to say people have different priorities. Selecting an appropriate point on multivariate system of tradeoffs is part of the skill of being a programmer. And if there's no point on the curve that delivers acceptable results in all categories — if, given a certain set of tools, it's not possible to ship quickly and deliver acceptable performance — then it should be an impetus for the programmer, the craftsman, to find better tools, improve his skills, push the "production curve" outward, until he can meet all the requirements.

For instance, a large percentage of modern programmers don't really know how to program from first principles, and tell the computer to do precisely and only the thing it needs to do. Essentially they only know how to glue tools together. Then in their head they're like, well gee, given that skillset, I could either (1) spend a bunch of time optimizing "hot spots," writing crazy algorithms, heroically trying to fight through all that slowness... or I could just (2) deliver the business logic and call it a day. Then they call this "prioritizing business requirements." No, there's a third, alternative, better option, which is to use better tools, which might initially be harder and more time consuming and less ergonomic to use, and then learning to get good with those tools, putting in the practice, recognizing patterns, thinking faster over time, coding faster... all of this is part of what mastering the trade of programming is about.

At the end of the day, there is just an ethic of self improvement and craftsmanship that is totally missing from programming today, and it surfaces whenever this debate comes up.

Re: Performance excuses debunked

#123

Post by brhsagain »

onion2k wrote: post #94
li4ick wrote: post #87

You know, reading these comments is absolutely hilarious. It's because of this and that, hundreds of excuses that dance around the simple truth: you're an incompetent programmer. That's it. No, you're not capable of making something twice as fast if only you cared or had the time. If you haven't done it as a constant exercise, you can't.

you're an incompetent programmer The problem with this line of reasoning, eg "if you write slow code you're incompetent", is that it applies to everything that programmers do - if you write slow code you're incompetent, if you write buggy code you're incompetent, if you write undocumented code you're incompetent, if you write untested code you're incompetent, if you write code slowly you're incompetent, if you write…

The flaw in this point is, there are really only a handful of measures that actually matter: writing performant code, shipping quickly, delivering business requirements (really this is an official sounding way of saying "doing the actual thing the program needs to do"), and eliminating bugs.

The other things are just proxies for the real measures, that people made up, and in fact are often harmful to the main goal. Like "documenting code" and "writing tests" a lot of the time are just cargo culting to make people feel like they're being responsible and following "best practices" without actually improving the measures that matter. I think that the other unlisted metrics in your "every measure someone dreams up..." are likely to fall under this category.

There isn't an infinite number of possible measures like you're suggesting, there's a finite number and a rather small number at that. You can definitely be really good or really bad at quickly shipping performant bug-free code that does its job. The problem in this debate is that one side is completely ignoring one of these measures, and trying to claim that it's because they have to prioritize the other ones, and that this is just an inevitable tradeoff, rather than that we lack the skill as an industry to do all of these things at an acceptable level. Being a good programmer may involve more axes than being a good chess player, but I think the claim that there are so many axes that it negates the existence of programming competence reductios to absurdum pretty quickly.

Re: Performance excuses debunked

#124

Post by jskdndkfm »

brhsagain wrote: post #123
onion2k wrote: post #94

Earlier quoted context omitted.

you're an incompetent programmer The problem with this line of reasoning, eg "if you write slow code you're incompetent", is that it applies to everything that programmers do - if you write slow code you're incompetent, if you write buggy code you're incompetent, if you write undocumented code you're incompetent, if you write untested code you're incompetent, if you write code slowly you're incompetent, if you write…

The flaw in this point is, there are really only a handful of measures that actually matter: writing performant code, shipping quickly, delivering business requirements (really this is an official sounding way of saying "doing the actual thing the program needs to do"), and eliminating bugs. The other things are just proxies for the real measures, that people made up, and in fact are often harmful to the main goal. L…

100%. Just claim that documentation and tests are cargo cults, take up previous cpu and memory like it’s 1985, and pretend that your shite, undocumented, unmaintainable, untestable, shift-right code is perfect.

Working with your type sucks. Confidently incorrect all the fucking time.

Re: Performance excuses debunked

#125

Post by li4ick »

archagon wrote: post #119
li4ick wrote: post #87

You know, reading these comments is absolutely hilarious. It's because of this and that, hundreds of excuses that dance around the simple truth: you're an incompetent programmer. That's it. No, you're not capable of making something twice as fast if only you cared or had the time. If you haven't done it as a constant exercise, you can't.

Hot tip: if you come into a conversation for the sole purpose of condescendingly insulting everyone, maybe put the phone down and take a breather. On a related note: https://xkcd.com/359/

I have no idea how you would take what I wrote as an insult. It's insulting to me that people are paid 400k a year and still think that what I wrote is somehow NOT the baseline. It's not even a debate. I'm gonna take my own advice from the past and block HN for another 3 years and get back to work. Good luck.

Re: Performance excuses debunked

#126

Post by JanneVee »

gonzo41 wrote: post #117
shrimp_emoji wrote: post #78

Earlier quoted context omitted.

> RAM is so big these days that most databases can fit into it and be blazingly fast. ... Compared to L3 cache? Isn't that still at least 10 times faster? That probably only matters in high performance projects though. > the correct way to structure IF statements (Common case first etc) But muh early returns on error D:

The point I was making is that a trip to disk is generally not occurring, and that having a soup of pointers in RAM isn't as bad having badly laid out memory on disk that needs to be paged in. Most performance being lost, isn't from memory layout patterns and not getting full pages. It's not even that much from bad branch prediction. Most of the bad performance these days is the stacks of extra app layers that exists…

And I see comments saying that Casey is doing some strawman thing here and yet here you are with claim "1. No need".

I'm just coming here with personal experience and my own anecdote that memory layout does matter even on modern CPU:s and it isn't niche. And because it was designed with OO mindset there wasn't any quick fix available.

Re: Performance excuses debunked

#127

Post by Hikikomori »

theptip wrote: post #99

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…

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

Re: Performance excuses debunked

#128

Post by Jach »

School-Cotton wrote: post #45

Absolutely hilarious and ridiculous to claim that Facebook cares about iOS app performance. In reality they have a few dozen people who care making heroic technical fixes to mitigate the damage of thousands of people adding mountains of mediocre crap to the apps. If you care about performance from the beginning, you would never even get to the point where you’re saying “oh crap, our messenger app can barely run, let’…

Late to the party but this is the same point of disagreement I had with the video, though overall it was fine. Why do these performance efforts and rewrites at the companies he listed take years? How complex is the uber eats app anyway? Well, it's because most engineers at those (and other) companies do not care or know about performance, and when it actually matters to the business, have to be dragged kicking and screaming to a slightly better state by the minority who do. It won't last long (hence the continued twitter examples).

Re: Performance excuses debunked

#129

Post by alex7734 »

asynchronous wrote: post #89
li4ick wrote: post #87

You know, reading these comments is absolutely hilarious. It's because of this and that, hundreds of excuses that dance around the simple truth: you're an incompetent programmer. That's it. No, you're not capable of making something twice as fast if only you cared or had the time. If you haven't done it as a constant exercise, you can't.

The sentiment here and in most of industry is: “and that doesn’t matter.”

In some sectors software quality truly does not matter beyond a certain point (and the bar is really low). The customer very rarely has the resources or the time to try all the alternatives, especially if switching afterwards is expensive so if your marketing is good and your product works and has the needed features, you get sales, and if it's not, you don't.

Is it terrible that the app takes minutes to add a few thousand numbers? Of course it is. But it does not matter, the customer is used to software being terrible so he won't waste the time and money to switch to another software that is probably also terrible.

Re: Performance excuses debunked

#130

Post by horsawlarway »

AbsoluteCabbage wrote: post #120
horsawlarway wrote: post #83

Earlier quoted context omitted.

I can rephrase your sentence as: The point is that performance is so far down the list of things to prioritize that [company of choice] made it to [revenue] without having to care at all about it. It wasn't worth them focusing on until they had already acquired a very large marketshare. Only when already large and successful did the scope and complexity of their system impact performance enough to bother focusing on…

“ Where you fall is a discussion to be had, because like ALL product requirements, it comes with a cost to develop and maintain. I don't drive an F1 car to the grocery store. I don't take my minivan to the track” No. The authors point is that you don’t have to drive an F1 car to the grocery store. All you have to do is stop slashing your tires, dumping sugar in your gas tank and driving a Kia. The amount of mental gy…

I somehow don't think I'm the one with the delicate little worldview in this conversation.

I think the delicate little worldview is the folks who consistently refuse to accept that performance just doesn't matter that much.

When performance does matter, it's usually because the value provided by the service is SUPER FUCKING LOW.

like say... twitter, or facebook. Which both are so worthless they can't reliably get users to pay for the service at all, and instead are selling ads to users and need to optimize the time they spend on the site.

Basically - if the difference between a customer choosing your product or not is latency measured in ms/seconds... you sell a fucking shite product.

Guessing you sell a fucking shitty product?

Post reply on HN