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

371–380 of 932 posts

Re: “Clean” code, horrible performance

#371

Post by badsectoracula »

fvdessen wrote: post #319
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…

If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler will not give you any idea that it could be still 10x faster.

If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize.

If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless [..] Notice that the above definition most emphatically does not say anything about making the software as fast as possible".[0]

[0] https://www.jagregory.com/abrash-black-book/#understanding-h...

Re: “Clean” code, horrible performance

#372

Post by Mizoguchi »

The problem with this is that in most real world scenarios it is much cheaper to add more hardware resources to slow performing apps than hiring, training and retaining programmers to learn, debug, enhance and maintain poorly written code, particularly when the useful life of many software solutions can last decades and hardware becomes cheaper every year.

Re: “Clean” code, horrible performance

#373

Post by adamrezich »

xupybd wrote: post #219

>It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier. Our job is to write programs that run well on the hardware that we are given. If this is how bad these rules cause software to perform, they simply aren't acceptable. That is not our job! Our job is to solve business problems within the constraints we are given. No…

everything with computers being slow and janky these days despite running on hardware that we could have only dreamed of mere decades ago is somebody's fault—if not ours, then whose?

you can only excuse-kick the blame-can down the time-road so far.

Re: “Clean” code, horrible performance

#374

Post by saagarjha »

jiggawatts wrote: post #322
p1necone wrote: post #293

Earlier quoted context omitted.

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…

Casey makes the point that you don't have to hand-tune assembly code, but instead just write the simpler code . It's easier to write, easier to read, and runs faster too! If there's something wrong with that advice, I can't imagine what it is...

The problem is that Casey has a very particular definition of simple which is problematic to apply in many cases.

Re: “Clean” code, horrible performance

#375

Post by Octokiddie »

> 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, impling that code following that rule number is 1.5x slower than code that doesn’t. To put that in in hardware terms, it would be like taking an iPhone 14 Pro Max and reducing it to an iPhone 11 Pro Max. It's three or four years of hardware evolution erased because somebody said to use polymorphism instead of switch statements.

The benchmark is a tight loop where the vtable lookup is a big chunk of the total computation. I don't think one can extrapolate this 1.5x improvement to real code. If anything, it represents an upper bound on the performance improvement you might expect to see.

I also didn't see anything about how the code was compiled. Various optimizations could affect performance in meaningful ways.

Re: “Clean” code, horrible performance

#376

Post by oakpond »

I'm sympathetic to the rebellion against 'clean code'.

I think this obsession with clean code is a natural reaction to the overwhelming number of gotchas that seem to just come with the job.

It's a bit like when a parent watches their kid get hurt outside the house and in a complete overreaction locks the kid in the house for life.

Thing is, if I'm programming an airplane control system, I very much want that kind of pedantry I think. I really don't want to make a single mistake writing that kind of program. If I'm programming a video game, just let me write the code that I want. Nobody's going to die if it blows up in my face.

I'm not sure what should be the lesson from all this... Perhaps don't pick C++ unless you absolutely need to?

Re: “Clean” code, horrible performance

#377

Post by saagarjha »

badsectoracula wrote: post #371
fvdessen wrote: post #319

Earlier quoted context omitted.

If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler will not give you any idea that it could be still 10x faster.

If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The…

> If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize.

No, though s/any/many/ would make this true.

Re: “Clean” code, horrible performance

#378

Post by adamrezich »

kps wrote: post #306
davnicwil wrote: post #61

I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).

The context for the author is game development. A game can't just spin up a few more servers in the cloud. The slower the code, the smaller the customer base. Some fields have more severe constraints, where developer time may be expensive, but compute is priceless. (This is not to endorse writing code that is harder than necessary to understand, or failing to document the parts that are necessarily hard.)

this video is part of a course that is not at all specific to game development, in any way whatsoever—where do these excuses come from?

Re: “Clean” code, horrible performance

#379

Post by hinkley »

randomdata wrote: post #350
hinkley wrote: post #320

Earlier quoted context omitted.

It doesn't. TDD is about writing new code. It doesn't say anything about existing tests being sacrosanct, or pinning tests sticking around forever. I can extract code from a function and write tests for it. I probably know that there's still code that checks for user names but I can't guarantee that this code is being called from function X anymore, or whether it's before or after calling function Y. Those are the so…

> TDD is about writing new code. TDD is about documenting behaviour. Which is why it was later given the name Behaviour Driven Development (BDD), to dispel the myths that it is about testing. It is true that you need to document behaviour before writing code, else how would you know what to write? Even outside of TDD you need to document the behaviour some way before you can know what needs to be written. A function'…

Also, to clarify, I'm talking about cumulative changes. If I'm working with someone on a feature then we both see all of the changes as they occur. If I'm off dealing with some long initiative, I may not look at that code for 3 months and so I miss all of the intermediate states that made perfect sense at the time.

Like visiting a friend who did their own house remodel. Their spouse saw all the steps, all you saw was before and after, and so the fact that the bathroom door is missing is confusing. The bathroom still exists, but now it's the master bath.

Re: “Clean” code, horrible performance

#380

Post by loup-vaillant »

AnIdiotOnTheNet wrote: post #217
chpatrick wrote: post #200

Earlier quoted context omitted.

Often it's because of bad (quadratic) algorithms, not because the code isn't micro-optimized. For example: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

It isn't about "micro-optimization", that's just what bad developers use as an excuse for never caring at all about performance. Casey uses the term "depessimization" to describe the process of making a program not run like shit. Modern computers are ludicrously fast, and modern developers have somehow managed to make them slow. Regardless, these programs should be spending 99% of their time waiting for user input, b…

https://www.lesswrong.com/tag/scope-insensitivity

Emotionally we have no idea how bad it is to waste as little as a few seconds per day for millions of users. It's just a few seconds, right? We're just forgetting to multiply those seconds by the number of users.

Post reply on HN