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

101–110 of 130 posts

Re: Performance excuses debunked

#101

Post by yonixw »

AbsoluteCabbage wrote: post #56
ftxbro wrote: post #37

So the biggest tech companies in the world, now that they are huge, are making their programs faster. OK. To me, that says maybe the reason they beat their competition to becoming huge, was that they wrote a lot of features quickly and didn't nitpick about performance. Maybe the ones that wrote efficient high performance code from the start stayed small or were out-competed.

you realize that you are literally parroting talking points that we have already predicted you would come up with as additional excuses, right?

He didn't refute "start faster, refactor later" at all, with any of his examples. So him saying he did, does not matter. "Evidence" as he says, is needed.

Re: Performance excuses debunked

#102

Post by onion2k »

li4ick wrote: post #97
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…

I mean, sure, this comment sounds nice on a web forum, but some of us have 0 hesitance bucketing others on a scale of competence. Looking at the state of software I interact with on a daily basis, I really don't care about being nice anymore.

some of us have 0 hesitance bucketing others on a scale of competence

Sure, and what I'm saying is that there are many scales, and all of us are at the incompetent end of some of them.

Re: Performance excuses debunked

#103

Post by yonixw »

simula67 wrote: post #44
ftxbro wrote: post #37

So the biggest tech companies in the world, now that they are huge, are making their programs faster. OK. To me, that says maybe the reason they beat their competition to becoming huge, was that they wrote a lot of features quickly and didn't nitpick about performance. Maybe the ones that wrote efficient high performance code from the start stayed small or were out-competed.

When I was starting out using the web, one of the reasons for using Google over competition was that it was fast. The home page loaded fairly quickly, and the results were instantaneous. Google spent a lot of time optimizing for performance during its early years and they were explicit about it.

The problem with this argument is that there are many contradicting sample points. Like chrome.

On one hand, Google created the JS-Engine V8 which finally made the web fast. But on the other hand, did nothing to fix the RAM issues that came with that until recent years.

So I see it as "Let's do performance only when it's an advantage for us". Which all of the OP examples falls to. OP want to conclude from that that performance=advantage so everyone need to work on it all the time (because who will ignore advantages?), but all we see is if(performance=advantage){refactor}. Which does not support his conclusion.

Example cases are startups, monopoles, high cost (like refactoring bank code) etc. which have other silos of advantage.

Re: Performance excuses debunked

#104

Post by gizmo »

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…

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.

Re: Performance excuses debunked

#105

Post by theamk »

lesuorac wrote: post #95
asynchronous wrote: post #89

Earlier quoted context omitted.

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

The general problem though is that "and that doesn't matter" isn't backed up by anything but gut feeling. When FB dove into the numbers, they found they could save 50% in hardware costs. That _does_ matter. It may be the case that your company has a 20k server rack to support 20M of sales and so it doesn't matter. But unless you've actually looked up the cost you shouldn't be making the claim because it's unbacked; i…

The argument is not that performance optimization does not matter at all, but rather than low-level performance optimization, like rewriting compilers, writing your own custom storage system, or rewriting it in unreadable speed-optimized C++ is worth it.

You don't need to do a deep analysis to tell if optimization is needed or not, it is enough to assume best-case improvements and compare it to your FTE + overhead cost.

Do you have many of your servers run CPU-bound C++ apps you wrote? If not, don't bother eliminating class hierarchies, optimize your core logic instead.

Do your webapps spend most time waiting on database and microservices? See if you can eliminate or cache those, the wins are going to be much bigger than rewriting it in Rust.

Is your GraphQL compiler too slow? Unless you are FAANG with hundreds of thosands of developers and hundreds of people to spare, you will get much more bang-for-the-buck with some smart caching or just getting a bigger machine for CI jobs.

According to levels.fyi, the average senior SW engineer in San Francisco is $312k/year. With overhead, the actual cost is likely $500k/yer or so. There is _a lot_ of servers you can buy for that money before you can justify maintaining your own custom version of the existing software solution.

Re: Performance excuses debunked

#106

Post by matiasfernandez »

yonixw wrote: post #101
AbsoluteCabbage wrote: post #56

Earlier quoted context omitted.

you realize that you are literally parroting talking points that we have already predicted you would come up with as additional excuses, right?

He didn't refute "start faster, refactor later" at all, with any of his examples. So him saying he did, does not matter. "Evidence" as he says, is needed.

“For example, one argument would be that the evidence I’ve presented here is consistent with a strategy of quickly shipping “version one” with poor performance, then starting work on a high-performance “version two” to replace it. That would be completely consistent with the evidence we see.

But even if that turns out to be true, it still means programmers have to care about performance! It just means they need to learn two modes of programming: “throw-away”, and “performant”. There would still be no excuse for dismissing performance as a critical skill, because you always know the throw-away version has to be replaced with a more performant version in short order.

That kind of argument is great. We should have it. What we should not have are excuses — claims there is no argument to be had, and that performance somehow won’t matter anywhere in a product lifecycle, so developers simply don’t have to learn about it.”

Re: Performance excuses debunked

#107

Post by [deleted] »

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…

[deleted]

Re: Performance excuses debunked

#108

Post by magicalhippo »

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…

> in my industry they don't care about performance until it's a noticeable problem

Yeah, I've done several dozen 10x or more performance improvements on our codebase. It's not always trivial, but most of the time it's not super-hard either.

In fact just today I did a 10x speedup of a query. After a couple of hours analyzing the issue, the fix was relatively simple: populate some temp tables before running the main query. A bit more complex than just running the query, but not terribly so.

Why hadn't we done that before? Because a customer suddenly got 1000x the volume of the previously largest user of that module, and so performance was suddenly not acceptable. It's 5 years since we introduced the module...

Re: Performance excuses debunked

#109

Post by lesuorac »

theamk wrote: post #105
lesuorac wrote: post #95

Earlier quoted context omitted.

The general problem though is that "and that doesn't matter" isn't backed up by anything but gut feeling. When FB dove into the numbers, they found they could save 50% in hardware costs. That _does_ matter. It may be the case that your company has a 20k server rack to support 20M of sales and so it doesn't matter. But unless you've actually looked up the cost you shouldn't be making the claim because it's unbacked; i…

The argument is not that performance optimization does not matter at all, but rather than low-level performance optimization, like rewriting compilers, writing your own custom storage system, or rewriting it in unreadable speed-optimized C++ is worth it. You don't need to do a deep analysis to tell if optimization is needed or not, it is enough to assume best-case improvements and compare it to your FTE + overhead co…

> The argument is not that performance optimization does not matter at all, but rather than low-level performance optimization, like rewriting compilers, writing your own custom storage system, or rewriting it in unreadable speed-optimized C++ is worth it.

People use these excuses for all kinds of performance arguments besides low-level/etc.

> You don't need to do a deep analysis to tell if optimization is needed or not, it is enough to assume best-case improvements and compare it to your FTE + overhead cost.

Sure, my point is people haven't even done rough math of FTE + overhead cost or even best-case improvements while still making those claims.

---

Less w.r.t. the article and more w.r.t. li4ick's comment. I've found numerous 10x gains in performance just by swapping an O(N^2) with an O(N) one (typically converting code using a List to using a Set instead). That doesn't cost 312k and if the original author was more concerned with performance they wouldn't've done things that way.

Re: Performance excuses debunked

#110

Post by ehaliewicz2 »

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…

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.
Post reply on HN