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

111–120 of 130 posts

Re: Performance excuses debunked

#111

Post by tmtvl »

shrimp_emoji wrote: post #78
gonzo41 wrote: post #73

Earlier quoted context omitted.

That's not really true anymore. RAM is so big these days that most databases can fit into it and be blazingly fast. It's all the classic shit that slows people down. Loops in loops in loops in loop with nested if's. Not understanding the correct way to structure IF statements (Common case first etc).

> 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:

According to Intel* RAM is about 2x L3 cache. Which is about 10x L2, which is about 4x L1. So:

  RAM := 1
  L3 := 2
  L2 := 20
  L1 := 80
* https://www.intel.com/content/www/us/en/developer/articles/t...

Re: Performance excuses debunked

#112

Post by _aavaa_ »

tmtvl wrote: post #111
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:

According to Intel* RAM is about 2x L3 cache. Which is about 10x L2, which is about 4x L1. So: RAM := 1 L3 := 2 L2 := 20 L1 := 80 * https://www.intel.com/content/www/us/en/developer/articles/t...

That's latency, and it's for a 16 core. The bandwith is shown there to be at least 1/4.

Re: Performance excuses debunked

#113

Post by marcosdumay »

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

Yeah, people like that exist... That has a strong and reverse correlation with competence.

Re: Performance excuses debunked

#114

Post by Tomis02 »

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…

> 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.

Re: Performance excuses debunked

#115

Post by musicale »

tomas789 wrote: post #35

One more datapoint here. Good performance helps avoiding scaling problems. One example is an API I recently wrote. I was initially in Python and performance was OK I guess. I had to take care of horizontal scaling, how to manage the infrastructure, a bit of distributed scaling and all the other goodies that come along. By rewriting it in Rust and caring about performance I was able to run it on a single machine (whic…

Rewriting your C++ app in Python can help it scale from 1000 servers to 100,000 servers without an increase in total throughput (although latency may increase.)

It can also scale your power usage up from 1KW to 1000KW.

If you have a datacenter that is 99% idle, you may be able to maximize utilization by switching to Python.

Re: Performance excuses debunked

#116

Post by li4ick »

marcosdumay wrote: post #113
li4ick wrote: post #97

Earlier quoted context omitted.

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 Yeah, people like that exist... That has a strong and reverse correlation with competence.

This makes absolutely 0 sense.

Re: Performance excuses debunked

#117

Post by gonzo41 »

shrimp_emoji wrote: post #78
gonzo41 wrote: post #73

Earlier quoted context omitted.

That's not really true anymore. RAM is so big these days that most databases can fit into it and be blazingly fast. It's all the classic shit that slows people down. Loops in loops in loops in loop with nested if's. Not understanding the correct way to structure IF statements (Common case first etc).

> 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 for little benefit.

Re: Performance excuses debunked

#118

Post by [deleted] »

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.

[deleted]

Re: Performance excuses debunked

#119

Post by archagon »

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/

Re: Performance excuses debunked

#120

Post by AbsoluteCabbage »

horsawlarway wrote: post #83
AbsoluteCabbage wrote: post #58

Earlier quoted context omitted.

The point is that performance is so important to customer satisfaction and the bottom line that even a horrendous company like facebook would begrudgingly spend time and money to improve performance. If anything your comment reinforces his point.

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 gymnastics you people go through to keep your delicate little worldview from crumbling is truly a sight to behold. Thank god we have people like Casey in this world to balance out the bell curve.

Post reply on HN