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

31–40 of 130 posts

Re: Performance excuses debunked

#31

Post by hikawaii »

paul_grisham wrote: post #15
db48x wrote: post #14

Earlier quoted context omitted.

Yes, there are definitely people who argue that performance never matters. And the research Facebook (and others) have done clearly shows that a half–second loading time on a webpage loses them a lot of money. So much money that they were willing to have dozens to hundreds of engineers work for years to fix it across all of their apps and their web servers and apis. Presumably it costs a small–time business a similar…

>Yes, there are definitely people who argue that performance never matters. Never seen one, post an example. >half–second loading time on a webpage loses them a lot of money. I didn't say milliseconds don't matter, I said it was diminishing returns. The size of those returns depend on the business. For Facebook it matters because users have other options to use their attention on such as Youtube and other social medi…

He's bringing out the men made of straw because there's a culture in many places, including my work, of YAGNI.

We did not properly federate many of our services and aystems, it is costing us tons of person hours to work around or deal with as our org chart grows. However, it's exactly the kind of thing that unlike Facebook - it is difficult to get metrics on how many dollars it will save or create, so it doesn't get fixed and people still wonder why anyone would care enough to fix it.

Re: Performance excuses debunked

#32

Post by kragen »

BlackFly wrote: post #18
db48x wrote: post #11

Earlier quoted context omitted.

Did you read the same article I did? He explicitly states exactly that: > 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 mean…

The problem is he has presented strawman arguments. If you are genuinely arguing with someone who believes performance never matters, stop arguing, you won't change that person's mind. Generally you will be arguing with a person who is considering the opportunity cost, but has considered it so many times and performance always lost, so they start saying (but not meaning literally) never. To this person you need to ma…

generally i'm arguing with a novice programmer who thinks they're an expert, but doesn't know anything about performance, but thinks performance isn't ever important

that said, it's just as common to be arguing with a novice programmer who thinks they're an expert, but doesn't know anything about performance, but is convinced of the critical overriding importance of the difference between n lg n and n squared when n is 5

Re: Performance excuses debunked

#33

Post by devjab »

Performance matters, but I’m not sure people are saying that it doesn’t. I’m not a performance “first” type of programmer by any means, but I always keep it in the back of my mind, what I also tend to keep in the back of my mind is cost.

I recently “inherited” a couple of back-end services when a developer left our company. It turned out that the code was terrible and that they haven’t used, any, or our helper tools. Since we use Typescript everywhere ignoring our quite opinionated and a little fascist linter rules is almost impossible, but the developer in question had the authority to turn it off, which they did and in doing so shot themselves completely in the foot. The back-end services were developed in JavaScript more than Typescript and since both our linters and usual teat pipelines were disabled, and since it’s software that has been developed over almost a years worth of changes, it was just horrible. We’re talking loops comparing values, that were probably there once but are now just sorting things as undefined === undefined kinds of terrible.

The performance was also atrocious. Basically what the service did was gather info on a couple of thousand projects and link them with tens of thousands documents in Sharepoint, but because it was build wrong, it wasn’t pulling the correct documents and it was taking 5-10 minutes each run time. It’s now running at around 10 seconds for its complete run time. Which is a massive performance improvement, and it’ll be even better once I finish building the cashing. So you might think I’m inclined to agree with the article, but I didn’t rewrite it because of its poor performance, I rewrote it because it didn’t work correctly and the performance gains were simply a happy “coincidence”.

This is because the performance didn’t really matter. Yes, it was costing us at most $77 a over our 3 year Azure contract, but the time I spent rebuilding it cost the company almost exactly $1500. Those $1500 were well spent because it wasn’t working, but would they have been well spent in terms of performance? Not really. That being said, it wouldn’t take a lot of those services to become expensive, so it’s not like the author is really wrong either. It’s just that I’m confused with whom he is arguing.

Re: Performance excuses debunked

#34

Post by vgatherps »

kragen wrote: post #29
omnicognate wrote: post #24

Earlier quoted context omitted.

He's a games programmer. He's using examples outside his industry to illustrate that his points aren't specific to games (excuse 4). What industry would you like him to talk about?

smes doing hourly contract crud development startups

To be fair, performance is usually part of the “does it work in real life” question, it’s just that doing sensible things is probably good enough.

The crud app at your startup probably doesn’t need to worry about cutting optimizing every last millisecond off of page load or scaling across some k8s cluster or whatever. But I’ve stopped using (or never seriously tried) otherwise good services because of flow-stopping performance problems i.e. multi-second page loads, stuttering pages, battery drain, etc.

Re: Performance excuses debunked

#35

Post by tomas789 »

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 (which is ok for that product). That saved me quite some hustle. And my average response time went from 300ms to 29ms.

If the app would scale a lot I would still need to go into all that trouble but at this early stage the benefits of really simple infrastructure is immense.

Re: Performance excuses debunked

#36

Post by kragen »

vgatherps wrote: post #34
kragen wrote: post #29

Earlier quoted context omitted.

smes doing hourly contract crud development startups

To be fair, performance is usually part of the “does it work in real life” question, it’s just that doing sensible things is probably good enough. The crud app at your startup probably doesn’t need to worry about cutting optimizing every last millisecond off of page load or scaling across some k8s cluster or whatever. But I’ve stopped using (or never seriously tried) otherwise good services because of flow-stopping p…

i'm not the one you need to convince, i'm just saying what marketing collateral i need to convince the skeptical: specific, detailed stories from those sectors, ideally at least somewhat verifiable (not a pseudonymous comment your wife's cousin read on hn)

but specific and detailed goes a long way

Re: Performance excuses debunked

#37

Post by ftxbro »

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.

Re: Performance excuses debunked

#38

Post by globalreset »

HideousKojima wrote: post #21
globalreset wrote: post #17

Scale / data set size tends to expose performance issues. But that's a good problem to have. Yes, it would be great if all developers could write performant code, but let's face it - there's only so many hours in a day and days in a week. Developers already struggle to keep up with all the required knowledge. It's not that people don't want to be competent. We're building more and more complex things while expanding…

>It's not that people don't want to be competent. There are plenty of devs that are just there for the paycheck and have minimal passion or interest in learning more.

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.

Re: Performance excuses debunked

#39

Post by yen223 »

It bothers me that all the examples provided shows that companies care about performance ("Company $X made their app 20% faster"), but none of them talks about the impact of caring about performance ("Company $X made their app 20% faster, and saw a 200% increase in revenue as a result")

Re: Performance excuses debunked

#40

Post by xupybd »

The author fails to make the business case for their arguments. Performance tuning costs money. Don't spend money with no expected ROI.

Yes at Facebook with end user facing software it is crucial to get performance right. If you're running payroll at a 3 person company it doesn't matter if the software is inefficient. Most of the time it's Excel, and that is not the most efficient way to do those calculations. But it's not worth investing in a better solution until processing payroll is a problem.

Post reply on HN