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

61–70 of 130 posts

Re: Performance excuses debunked

#61

Post by ftxbro »

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?

I mean I'm not parroting anything, but OK I will also agree that this isn't an especially mind blowing point that I was making. Probably a lot of other people would make that same point too!

Re: Performance excuses debunked

#62

Post by AbsoluteCabbage »

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

No, his previous video cited that premise.

This video was clearly about debunking your excuses, which he did succinctly.

Re: Performance excuses debunked

#63

Post by jiggawatts »

runlaszlorun wrote: post #26
jiggawatts wrote: post #16

Earlier quoted context omitted.

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…

I’ve always enjoyed perf testing and optimization but figured it’d be tough to reliably find clients staying in that niche. Any tips?

I never got enough of this type myself, they were just random gigs between other types of project work.

IMHO, the IT industry as a whole has internalised wastefulness and accepted poor performance because there's an expectation that "CPU upgrades will fix it". Over five decades that was true, it's just that few organisations have adapted to the new reality of only ~20% uplifts in single-thread performance over the last decade or so.

In principle, there ought to be many more optimisation projects, but unfortunately they're still rare.

Re: Performance excuses debunked

#64

Post by BlackFly »

kragen wrote: post #32
BlackFly wrote: post #18

Earlier quoted context omitted.

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…

Haha, yes I have had similar experience with people focusing on asymptomatics. I think you are correct, these arguments could be good for a junior, but definitely not an obstinate one.

Re: Performance excuses debunked

#65

Post by kaba0 »

JanneVee wrote: post #49

Well then further excuses come flying on why he is wrong again, and how performance doesn't matter to them. I have a legacy code base that I until recently worked with that domain specific Business Intelligence product built with SOLID principles. 20% of the processes CPU usage was for the GC, whenever you made a dump of the process it was 99% fragmentation of memory and pointer chasing through object trees every tim…

And what exactly is that advice? Most programs are not game engines operating upon millions of entities with the same basic logic.

The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in such a setting, at all - the way you might speed up the app is doing the work on the database itself, which is already written in some low-level language, efficiently.

Your anecdote is just a badly written application, I have plenty examples of very performant ones written in managed languages.

Re: Performance excuses debunked

#66

Post by Ekaros »

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.

So can't we just give those well metrics to get under. Or tell them that make it feel "snappy". And not accept the result until it feels good enough.

They are paid to do a job. Just have to specify what that job is in a correct way.

Re: Performance excuses debunked

#67

Post by JanneVee »

kaba0 wrote: post #65
JanneVee wrote: post #49

Well then further excuses come flying on why he is wrong again, and how performance doesn't matter to them. I have a legacy code base that I until recently worked with that domain specific Business Intelligence product built with SOLID principles. 20% of the processes CPU usage was for the GC, whenever you made a dump of the process it was 99% fragmentation of memory and pointer chasing through object trees every tim…

And what exactly is that advice? Most programs are not game engines operating upon millions of entities with the same basic logic. The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of…

The advice is that consider memory layout when doing repetitive operations on your data.

> The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in such a setting, at all - the way you might speed up the app is doing the work on the database itself, which is already written in some low-level language, efficiently.

No my example isn't a complaint on it using GC language. It is that it is loading and unloading business entities multiple times and doesn't take into account that operations could be done linearly much faster instead of hunting a field in object graph to accumulate in various ways. That is how e.g. numpy works if you make sure that the array you do your operation on is of the same type.

> Your anecdote is just a badly written application, I have plenty examples of very performant ones written in managed languages.

Yes following the ideas of what is considered SOLID principals. The objections isn't managed vs. unmanaged it is going full OO and not giving a shit about how computers work.

Re: Performance excuses debunked

#68

Post by kaba0 »

JanneVee wrote: post #67
kaba0 wrote: post #65

Earlier quoted context omitted.

And what exactly is that advice? Most programs are not game engines operating upon millions of entities with the same basic logic. The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of…

The advice is that consider memory layout when doing repetitive operations on your data. > The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in…

I don’t see how OO is at fault here, though.

Re: Performance excuses debunked

#70

Post by denieus »

I agree performance is important and we should aim to improve it if we can, but the cost x benefit of these improvements must be evaluated. It's easy to believe we're making huge gains when there's actually little gain added overall.

Two examples:

1. I've seen people mentioning that following good programming practices make the code slower, and by removing them you can have improvements around 40%. That sounds like a great number, until you realize the real bottleneck are other things (e.g. database queries, network latency, etc). When you calculate the overall improvement for the request, the gains are negligible.

2. There are some frameworks that market themselves as crazy fast: "If you use us your app will boot almost instantaneously!". Looks cool, until you realize that a good pipeline will gradually rollout a new version and this will take time. Usually it comes with monitoring the new version for a while and then after it's deemed healthy we switch versions completely. Now instead of waiting a few minutes + 10 seconds, you will wait only a few minutes, which doesn't make much difference.

Performance gains will come with tradeoffs and, before committing to that, it's a good idea to evaluate what are the real benefits of doing the changes we're planning to do.

Post reply on HN