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

81–90 of 130 posts

Re: Performance excuses debunked

#81

Post by cratermoon »

The author doesn't really debunk any of what he calls "excuses" when he jumps immediately to Facebook, then Twitter, Uber, Netflix, and Microsoft. Those are companies with huge scale problems. He even says as much, near the end, claiming "the evidence against these excuses comes from some of the largest and most financially valuable companies in the world". Nobody is arguing that performance doesn't matter at those scales.

Here's the author's five points, and how at least one of the examples he gives proves the reasons.

No need. These companies operate on the leading edge of hardware performance, on purpose. They can't just go out and buy faster hardware, it doesn't exist. Google even builds their own, just to optimize for their uses.

Too small. Again, at the scale of Facebook or Netflix, a 5% performance gain translates to an enormous advantage, which leads directly to the next point.

Not worth it. Here again, we're talking about saving millions of dollars but only because the systems are so enormous.

Niche. Facebook, Twitter, Netflix, and Uber's performance needs are a niche of their own.

Hostpot. Here we can get to a specific example the author quotes. "Cutting back on cookies required a few engineering tricks but was pretty straightforward; over six months we reduced the average cookie bytes per request by 42% (before gzip). To reduce HTML and CSS, our engineers developed a new library of reusable components (built on top of XHP) that would form the building blocks of all our pages."

So their Facebook does have a hotspot, it just happens that it's a very large spot on a colossal size system.

Finally, the author says, "If you look at readily-available, easy to interpret evidence, you can see that they are completely invalid excuses, and cannot possibly be good reasons to shut down an argument about performance."

I'm still looking for the evidence.

Re: Performance excuses debunked

#82

Post by cratermoon »

never_inline wrote: post #80
citrin_ru wrote: post #72

Earlier quoted context omitted.

O(1) hash vs O(N) array loop is a bit more complicated - for small N linear search can be faster - no need to compute a hash function, if data stored directly in the array (instead of pointers) then there will be less CPU cache misses. Exact threshold can be determined in a benchmark but the key here here is that N should be bounded - if a user can manipulate N to be huge and you have O(N^2) somewhere in your code it…

In this particular case, even if performance is not concern I would use the hash map. It just reads better.

Interestingly, some of the folks who harp about performance would see your "reads better" as a problem. I'm completely in agreement with the idea that, until the code is proven to be a performance problem, readability and clarity matters most. But the performance-first mavens would say the choice should be determined by Big-O performance and memory usage, then by readability.

Re: Performance excuses debunked

#83

Post by horsawlarway »

AbsoluteCabbage wrote: post #58
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’…

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 it, at which point they begrudgingly did.

----

Performance is simply a requirement for the product, some products require very good performance, some don't.

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.

The article above is bad - it treats a conversation about product requirements as an antagonistic space, where voices that may prioritize a feature other than performance aren't making judgements about how to allocate limited resources, but "excuses"... Worse - he cherry picks the most extreme take of those value judgements for his examples as easy targets to attack.

Re: Performance excuses debunked

#84

Post by cratermoon »

AbsoluteCabbage wrote: post #55
tomgp wrote: post #50

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.

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.

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.

Re: Performance excuses debunked

#85

Post by UK-Al05 »

eastbound wrote: post #43
globalreset wrote: post #38

Earlier quoted context omitted.

True, but it's normal in many professions that lots of people working in it are not passionate and industry just deals with it. We can't expect that average software developer is going to be passionate and spending their weekends honing every-increasing set of skills: technologies, platforms, tools, etc.

Can’t we? The entire startup ecosystem is based on extracting from the economy people who are motivated, do their work efficiently and learn high skills, and giving them millionaire-or-bankrupt stakes to ensure they’re committed.

The expected value from start-up shares is so low, you're bit of idiot if you're degrading your life for it.

Actual founder? Sure. Early employees get a raw deal. Honestly it better if you earn the most from salary, and invest the extra cash in startups. You'll get more equity.

Re: Performance excuses debunked

#86

Post by draw_down »

Is there no performance gain that’s small enough to be not worth it? If there is, then we’re just haggling over where the line is. If there truly isn’t, well, enjoy that! Because you won’t be shipping.

Re: Performance excuses debunked

#87

Post by li4ick »

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.

Re: Performance excuses debunked

#88

Post by kevincox »

charlie0 wrote: post #20

Starts off with premise of why performance matters and why you should care. Proceeds to only top 10 biggest tech companies as examples. Are you working in a FAANG? If not, this article does nothing to convince me that I should care about performance (even though I kinda do).

I don't think this is true. There are a lot of applications and services that I avoid because they are so slow that they are painful. I don't think you should be worrying about ensuring that your API is always <10ms but good general performance patterns (especially considering the scaling as you write code, limit yourself to O(n) unless you can be very sure that `n` will always be small) can keep you within interactive performance without needing to worry too much about it.

Re: Performance excuses debunked

#89

Post by asynchronous »

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

Re: Performance excuses debunked

#90

Post by kevincox »

citrin_ru wrote: post #72
magicalhippo wrote: post #13

There's often a lot of low hanging performance fruits when writing code. Need to loop over some order lines and find distinct article numbers? Use a hash-based set with O(1) access, not just a list which will have O(n). If not you'll end up writing an O(n^2) routine for no good reason, which will work swimmingly on you 10 line test order and cause grief in production. I don't think a lot about performance most of the…

O(1) hash vs O(N) array loop is a bit more complicated - for small N linear search can be faster - no need to compute a hash function, if data stored directly in the array (instead of pointers) then there will be less CPU cache misses. Exact threshold can be determined in a benchmark but the key here here is that N should be bounded - if a user can manipulate N to be huge and you have O(N^2) somewhere in your code it…

In my experience it is better to default to the lowest complexity algorithm. Even if linear search is faster for small N your app probably performs acceptably for small N either way. At some point being fast enough to be interactive is good enough and there isn't much point making your interactions take 2ms rather than 10ms.

However n^2 algorithms will bite you. They may be outside of your everyday working set, and even dogfooding you may not have larger datasets than all of your users. At some point one user will hit a dimension that you "expected to always be small" and get bad performance.

If one of these O(1)N algorithms ends up in the hot path you can always optimize it when profiling points it out. But O(N)N algorithms will leap off the cold path and become hot when some user starts using the "wrong" data patterns and the developers may never be aware, or at least not aware until it is too late.

Post reply on HN