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

751–760 of 932 posts

Re: “Clean” code, horrible performance

#751

Post by Applejinx »

DeathArrow wrote: post #671
fvdessen wrote: post #546

Earlier quoted context omitted.

Think of using slow patterns as using a slow programming language. After you've optimised your python program and eliminated all hotspots, the python profiler isn't going to say 'hey, this could be still 10x faster if rewritten in go'. Note that if you write a graphics engine, you aren't going to use python or even go, but something more like c, c++, rust, even though your code would be cleaner in python. Clean code…

>Clean code techniques elevate your level of abstraction and prevent some problems What problems do they prevent?

Unemployment :)

If you're able to make a program into a sort of puzzle concealing its state inside a twisty maze of tiny virtual functions so it's impossible to see plainly how anything is done, then you become indispensable as the only one who's internalized how the thing works.

And then you insist it's all for easier comprehension… for those sufficiently intelligent to comprehend it.

Re: “Clean” code, horrible performance

#752

Post by gureddio »

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…

The "contrived textbook example from 20 years ago" still has a very real impact today. In my experience there are still lots of development teams that are instructed to develop in a "Clean code" style in the flavour of Uncle Bob. It's especially true in the .net development space, and is almost a cultural problem within .net.

As a former .net developer that was often pushed into "clean code", my big takeaway from the video was that actually, not using "clean code" techniques, such as polymorphism made the code so much more readable and easier to grok that the optimisation that followed was completely natural.

Re: “Clean” code, horrible performance

#753

Post by DeathArrow »

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…

>CPU cycles are much cheaper than developer wages.

But using "clean code" and SOLID does not make the code faster to write, easier to maintain. It makes it harder to reason about and slower.

Re: “Clean” code, horrible performance

#754

Post by CuriousCosmic »

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…

Honestly in many cases you can have your cake and eat it too if you just write in a functional or data-flow style rather than a rigorous OO style. Since this is C++, using std::algorithm or another algorithms library would let you abstract your implementation details while relying on the compiler's ability to optimise/vectorise/inline code as needed.

This applies doubly so if you can rely on templates & structural typing to push your polymorphism to compile time. clang & gcc are surprisingly good at optimisation as long when you don't have to bounce off a vtable and code is clean / avoids "manual optimisation".

Also while I'm not saying I don't believe the author here, I wish they would have used https://quick-bench.com/ or https://godbolt.org/ so that readers could trivially verify the results & methodology.

Re: “Clean” code, horrible performance

#755

Post by fifticon »

whstl wrote: post #577
scotty79 wrote: post #257

Earlier quoted context omitted.

What does it matter if it does this 0.1% ten times slower than it could? Then user will have to wait for the software which slows the most expensive component of the whole work setup, the human.

It matters because, to give an example, Facebook still isn't fast enough to keep up with my typing speed. And I'm not that fast.

that is probably because they are so busy keylogging every single stroke you type :-/

Re: “Clean” code, horrible performance

#756

Post by WesolyKubeczek »

Zvez wrote: post #697
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.

no take your tupical web service application. Even if you use design patterns that are 10x slower, your program will still be as fast as your DB and overall system architecture. And the choices on your DB schema, indexes and caches will have 100x more effect on your 99pp response time than design pattern you use.

If you can remove thinly spread overhead from your web framework or any wasteful ritual dance you make for each request, it might not be much, but it does add up over the course of 24 hours * number of workers to quite a bit.

Re: “Clean” code, horrible performance

#757

Post by davidgrenier »

This thread is surprisingly back today with millions of comments. I don't know if anyone has pointed out that the functions called... do nothing. Hence it is understandable that the performance profile is dominated by dynamic dispatch.

Also, his code must have been compiled with an old compiler or less than -O3 as the switch/table version of the code performs exactly the same with Clang and g++ when compiled with -O3.

disclaimer: not a fan of OO regardless.

Re: “Clean” code, horrible performance

#758

Post by bigbacaloa »

munk-a wrote: post #517
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…

I'd actually say this article is generally unhelpful - it's good to be aware but as someone who works on sorting out performance critical things I want the code to be as clean as humanly possible going in. Whether you write clean or dirty code if you're a junior developer you're probably not going to write performant code and even senior devs may be able to sniff what might be a bottleneck in advance but most of us h…

Maintainability and cleanliness are not the best virtues code can have. Far more important are that it work correctly and quickly.

Re: “Clean” code, horrible performance

#760

Post by raspberry1337 »

rando14775 wrote: post #739
raspberry1337 wrote: post #726

Earlier quoted context omitted.

[flagged]

[flagged]

>Cars weren't as big a priority for the communists. They were right too, cars and car infrastructure are super inefficient.

How to say that you're a city kid, without saying you are a city kid.

Post reply on HN