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

291–300 of 932 posts

Re: “Clean” code, horrible performance

#291

Post by jimbob45 »

yashap wrote: post #263
mabbo wrote: post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

Well said. The aphorism "Premature optimization is the root of all evil" is meant to mean "Build it right first, then optimize only what needs to be optimized". There's really no need to start cooking spaghetti right off the bat. Clean code with some performance tweaks will be more maintainable in the long run without sacrificing performance.

Re: “Clean” code, horrible performance

#292

Post by rwalle »

gdprrrr wrote: post #251
josephg wrote: post #224

Earlier quoted context omitted.

> Things way worse than that exist. Yeah. I opened discord earlier, and it took about 10 seconds to open. My CPU is an apple M1, running about 3ghz per core. Assuming its single threaded (it wasn't), discord is taking about 30 billion cycles to open. (Or around 50 network round-trips at a 200ms ping). Crimes against performance are everywhere.

Have you measured CPU time? A very large factor will be Disk IO and Network

Exactly. The webpage is probably asking for resource from 10 different servers and one of them is a bit slower than the others, and the page rendering itself likely doesn't take very long.

Re: “Clean” code, horrible performance

#293

Post by p1necone »

yashap wrote: post #263
mabbo wrote: post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

Casey Muratori knows a lot about optimizing performance in game engines. He then assumes that all other software must be slow because of the exact same problems.

I think the core problem here is that he assumes that everything is inside a tight loop, because in a game engine that's rendering 60+ times a second (and probably running physics etc at a higher rate than that) that's almost always true.

Also the fact that his example of what "everyone" supposedly calls "clean code" looks like some contrived textbook example from 20 years ago strains his credibility.

Edit: come to think of it, the only person I know of who actually uses the phrase "clean code" as if it's some kind of concrete thing with actual rules is Uncle Bob. Is Casey assuming the entire commercial software industry === Uncle Bob? It's like he talked to one enterprise java dev like 10 years ago and based his opinion of the entire industry on them.

Re: “Clean” code, horrible performance

#294

Post by FridgeSeal »

bitwize wrote: post #255
bakugo wrote: post #210

Earlier quoted context omitted.

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something It's because of this mentality that almost all desktop software nowadays is bloated garbage that needs 2GB of RAM and a 5Ghz CPU to perform even the most basic task that could be done with 1/100th of the resources 20 years ago.

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.

> Most users aren't going to notice.

And other lies you can tell yourself to sleep at night.

Most people notice. Very few have the capacity, power (or realise) to complain about it. They accept what they’ve been given, despite how awful it is, because they have basically no other option.

A concrete example: my previous work had to use bitbucket pipelines for our docker builds. My current work uses GitHub actions. GH has my container half-built before I can even click through to the page. Bitbucket took a good minute to start. My complaints about bitbucket fell on deaf ears in the business, and no amount of leaving feedback for Atlassian to “please make builds faster” ever made the slightest amount of difference. Every time MS teams comes up that’s met with complaints about performance (among other things) so people definitely notice that. VS Code gets celebrated for “actually having decent performance”, so the bar is so low that even moderate performance apps receive high praise.

Users definitely notice performance, whether the PM/business cares is a different matter, but we should stop deceiving ourselves by saying it’s alright because “users won’t notice or care”.

Re: “Clean” code, horrible performance

#295

Post by the-smug-one »

FooBarWidget wrote: post #185
mabbo wrote: post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

Not only time to market, but also maintainability. In non-performance-critical areas, it's pretty important that when the original dev team leaves, new hires can still fix bugs and add features without breaking things.

I don't see how the code snippets presented are less maintainable.

Re: “Clean” code, horrible performance

#296

Post by runevault »

KyeRussell wrote: post #129

David Farley’s new book is good. It advocates for the tenants of “clean code” (at least in all lowercase), but given his background I trust that he knows how to balance performance and code hygiene. There are people that are wrong on both extremes, obviously. I’ve worked with one too many people that quite clearly have a deficient understanding of software patterns and try to pass it off as being contrarian speed fre…

He's a gamedev by trade who also used to work at RAD tools back in the day. You can argue he doesn't know how to work in large teams because I don't think he has, but when it comes to understanding CPUs (or GPUs) as well as a dev can he's about as capable as anyone on that front.

He is very much aggressive to a degree I am not a fan of, but when it comes to calling out bad practices, I find him more right than wrong. But he is terrible at delivering his message in a way that won't ensure anyone who didn't agree with him already will get pissed off.

Re: “Clean” code, horrible performance

#297

Post by garganzol »

The article gives an advice from the past. Nowadays it is all about zero-cost abstractions and automatic optimization. These trends will only solidify in the future defining the new norm. And until that future fully arrives, optimize for your bottlenecks.

Re: “Clean” code, horrible performance

#298

Post by datavirtue »

rodrigobellusci wrote: post #222
mquander wrote: post #196

Earlier quoted context omitted.

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high performance calculation software then sure, go crazy, get those improvements. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because o…

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.

Re: “Clean” code, horrible performance

#299

Post by magicalhippo »

p1necone wrote: post #293
yashap wrote: post #263

Earlier quoted context omitted.

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

Casey Muratori knows a lot about optimizing performance in game engines. He then assumes that all other software must be slow because of the exact same problems. I think the core problem here is that he assumes that everything is inside a tight loop, because in a game engine that's rendering 60+ times a second (and probably running physics etc at a higher rate than that) that's almost always true. Also the fact that…

Then again, thing's aren't in the critical path until suddenly they are.

Regardless of scenario I will never willingly do a O(n^2) sort when writing new code. Just in case those 10 items suddenly turn to 10000 one day.

Re: “Clean” code, horrible performance

#300

Post by AbusiveHNAdmin »

mabbo wrote: post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

"So by violating the first rule of clean code — which is one of its central tenants"

The word is TENET. Tenants rent stuff.

Post reply on HN