Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Clean” code, horrible performance

computerenhance.com

Post reply on HN
Print view View original

921–930 of 932 posts

Re: “Clean” code, horrible performance

#921

Post by inkblotuniverse »

xupybd wrote: post #460
alfalfasprout wrote: post #446

Earlier quoted context omitted.

The problem is I think you're also disagreeing with yourself in a way. > That is not our job! Our job is to solve business problems within the constraints we are given. No one cares how well it runs on the hardware we're given. They care if it solves the business problem. Look at Bitcoin, it burns hardware time as a proof of work. That solves a business problem. Cost is a business problem. It is a constraint. The pro…

> Cost is a business problem. It is a constraint I 100% agree. What I'm trying to get across is that you have to identify the cost to justify the performance tuning. If the cost of the tuning is greater than the cost incurred by not doing you might not want to do it. What are your actual costs and how do they line up? Are you writing ML and big data then processing costs are huge. You can probably win by spending mon…

There are 1000x gains on the table! Almost all software is so far from pareto-optimal it's comical! It isn't a tradeoff between readability and efficiency, most software is unreadable and inefficient!

When every function in your program is virtual, fixing bottlenecks won't give you a significant speedup. You don't need to optimize programs to make them 1000x faster, we just need to stop shooting ourselves in the foot.

Re: “Clean” code, horrible performance

#922

Post by inkblotuniverse »

WA wrote: post #643
noobermin wrote: post #641

This comment section just shows how so many developers are victims of group think. Here is actual evidence that at least hints that the primary paradigm is wrong, and immediately a bunch of nerds jump and attack, instead of taking the criticism in good faith. Compare this to discussions about FP, new languages like Rust, and so forth. This really demonstrates the primary vogue mindset is increasing complexity and hie…

What are you talking about? The first comment is literally a real sincere rebuttal: "performance doesn’t matter in 99.9% of apps".

90 percent of apps are slow and unreponsive, and harming people by being so: but software developers aren't directly harmed by the effects of their actions, so the situation continues.

Re: “Clean” code, horrible performance

#923

Post by inkblotuniverse »

commandlinefan wrote: post #273
boredumb wrote: post #204

I've seen clean code lead to over-architected and unmaintainable nightmares that ended up with incorrect abstractions that became much more of a problem than performance. The more the years pile up the more I agree with the sentiment in this post, generally going for something that works and is as optimal of code as I would get if I was to come back to make it more performance oriented in the future, I end up with so…

> I've seen clean code lead to over-architected and unmaintainable nightmares I agree, but surely you wouldn't really say that his end-state in this particular article is more maintainable than the starting point.

I'd say it is- I can read and delete the whole thing in 5 minutes if I need to replace it with something more complicated. Usually, though, YAGNI

Re: “Clean” code, horrible performance

#924

Post by joaonmatos »

dagw wrote: post #700
joaonmatos wrote: post #397

Earlier quoted context omitted.

Are you even manually implementing sorts frequently? Even languages that are notorious for having tiny libraries, like C and JS, have built-in sorts.

Perhaps not sort so much, but certainly with search I've seen people roll their own inefficient search functions many times.

It is the exact same situation, though. Most people can just chain a sort and a binary search to do it, and both are included in most languages. Or just put it into a tree map, if your language has it.

Re: “Clean” code, horrible performance

#925

Post by brewmarche »

ookdatnog wrote: post #645
noobermin wrote: post #641

This comment section just shows how so many developers are victims of group think. Here is actual evidence that at least hints that the primary paradigm is wrong, and immediately a bunch of nerds jump and attack, instead of taking the criticism in good faith. Compare this to discussions about FP, new languages like Rust, and so forth. This really demonstrates the primary vogue mindset is increasing complexity and hie…

I'm not sure why you're bringing up FP and Rust here. The idiomatic FP and Rust versions of the code in the article would be similar to the fast version: you use algebraic data types to represent your Shape type (which are just tagged unions under the hood, exactly like in the article) and pattern match on the type, which can be compiled to a jump table (exactly like in the article). And I think neither FP nor Rust d…

Agree. Typical FP with ADTs would lead to the same kind of data-driven style. The point at which he went too far for me is probably the struct layout optimisation (every shape has two defining numbers, it feels a bit restrictive). For me that’s the point where I’d check whether it’s really warranted and if so create new types to distinguish the original domain (Shape) vs. number crunching (ShapeDefinedByTwoNumbers - needs a better name).

Re: “Clean” code, horrible performance

#926

Post by rodrigobellusci »

datavirtue wrote: post #298
rodrigobellusci wrote: post #222

Earlier quoted context omitted.

Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.

I recently tried Vue 3 at a startup for a new app. A few days after starting it I rewrote a personal Svelte app in Vue 3 since I found it so fluid (Composition API w/ script setup). I was liking Svelte before that.

Oh that's interesting! Will definitely keep Vue 3 in mind for future then.

Re: “Clean” code, horrible performance

#927

Post by rodrigobellusci »

jay_kyburz wrote: post #232
rodrigobellusci wrote: post #222

Earlier quoted context omitted.

Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.

You should just try working directly in HTML.

For sure, I've been trying to cut down on dependencies and JS where possible.

I'm curious to give WebComponents a try as well.

Re: “Clean” code, horrible performance

#928

Post by dsattt »

noobermin wrote: post #641

This comment section just shows how so many developers are victims of group think. Here is actual evidence that at least hints that the primary paradigm is wrong, and immediately a bunch of nerds jump and attack, instead of taking the criticism in good faith. Compare this to discussions about FP, new languages like Rust, and so forth. This really demonstrates the primary vogue mindset is increasing complexity and hie…

I was thinking the same thing. Everybody is so desperate to ship features fast that any hint against it triggers a mob with a bloodlust.

Re: “Clean” code, horrible performance

#929

Post by verinus »

elxr wrote: post #668
bitwize wrote: post #255

Earlier quoted context omitted.

RAM and GPU are cheap. Most users aren't going to notice. Meanwhile by choosing Electron, the developers were able to roll out the app on Windows, Mac, and Linux at nearly zero marginal cost per additional platform.

RAM is not cheap if you look at what apple charges for it.

compared to hourly rates of devs- even around the world? really?

Re: “Clean” code, horrible performance

#930

Post by curtainsforus »

Aeolun wrote: post #479
TeMPOraL wrote: post #324

Earlier quoted context omitted.

Casey's implied point is that clean code is already sacrificing performance from the start. And of course real life tells us that those "performance tweaks" will never happen. There is this popular wisdom that security must be designed for from the start, and cannot be just added after the fact. Performance is like that too, except worse, because you actually can add security after the fact - worst-case, you treat th…

> Casey's implied point is that clean code is already sacrificing performance from the start. Where our opinion seems to diverge is where I accept that as being fine, for the sake of being clean/legible/understandable.

The argument continues to say that the 'clean code' version isn't actually cleaner/more legible/more understandable. I, for one, am royally sick of spending 5 minutes trying to figure out which virtual function implementation was actually called!
Post reply on HN