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

331–340 of 932 posts

Re: “Clean” code, horrible performance

#331

Post by DaiPlusPlus »

frankreyes wrote: post #63
vrnvu wrote: post #11

The problem with the contemporary "clean code" concept is that the narrative that performance and efficiency don't matter has been pushed down the throat of all programmers. Re-usability, OOP concepts or pure functional style, design patterns, TDD or XP methodologies are the only things that matter... And if you use them you will write "clean code". Even worse, the more concepts and abstractions you apply to your cod…

> the narrative that performance and efficiency don't matter That was the case during the 90s and the first decade of the 2000. Just wait for Moore's Law to kick in and in 18 months your code will get faster by an order of magnitude for free.

Moore's Law concerns IC transistor counts, not actual overall performance, and especially not single-threaded performance: a 40-core CPU isn't going to make Windows twice as fast as a 20-core CPU.

Single-threaded performance has long-since effectively plateaued: it's 2023 now and a desktop computer built 10 years ago (2013) can run Windows 11 just fine (ignoring the TPM thing) - but compare that to using a computer from 2003 in 2013 (where it'd run, but poorly), or a computer from 1993 in 2003 (which simply wouldn't work at all).

This is not to say that there won't be any significant performance gains to come, such as with rethinks in hardware (e.g. adding actual RAM into a desktop CPU package, non-volatile memory, etc) but I struggle to see how typical x86 MOV,CMP,JMP instructions could be executed sequentially any faster than they are right now.

Re: “Clean” code, horrible performance

#332

Post by rolldat777 »

ysavir wrote: post #188

As a general rule, optimize for your bottlenecks . If you have a large sum of I/O and can see the latency tracked and which parts of the code are problematic, optimize those parts for execution speed. If you have frequent code changes with an evolving product, and I/O that doesn't raise concerns, then optimize for code cleanliness. Never reach for a solution before you understand the problem. Once you understand the…

I think this is the point. In the example given, if you introduce a sqrt, then the argument becomes much weaker already. The dispatch is comparable to the computation time. I'm reminded of "Latency Numbers Every Programmer Should Know".

I actually just had this debate with myself, specifically about shape classes including circles and bezier curves. However, the operation was instead intersections. There was zero performance difference in that case after profiling so I kept the OOP so that the code wasn't full of case statements.

Re: “Clean” code, horrible performance

#333

Post by Taniwha »

stunpix wrote: post #150

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere "? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method…

Occasional CPU architect here .... probably the worst thing you can do in your code is to load something from memory (the core of method dispatch) and then jump to it, it sort of breaks many of the things we do to optimise our hardware - it causes CPU stalls, branch prediction failures, etc etc

There is one thing worse you can do (and I caught a C++ compiler doing it when we were profiling code while building an x86 clone years ago) instead of loading the address and jumping to it push the address then return to it, that not only breaks pipelines but also return stack optimisations

Re: “Clean” code, horrible performance

#334

Post by jiggawatts »

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.

Please just stop with this. It's plainly false.

At $dayjob I recommended some simple database query tuning that 1 developer applied in their spare time. This improved performance from 9 seconds per page to 500 milliseconds per page.

That customer wanted to use auto-scale to expand capacity (nearly 20-fold!) to meet the original requirements, which would have cost about $250K annually.

The dev fixed the issue in like... a week.

What developer costs $250K per week!? None. None do. Not even the top tier at a FAANG.

Not to mention the time saved for the thousands of users that use this web application. Their wasted time costs money too.

Re: “Clean” code, horrible performance

#335

Post by rudolph9 »

> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%

https://dl.acm.org/doi/10.1145/356635.356640

The author of the post fails to articulate how we strike a healthy balance and instead comes up with contrived examples to prove points that only really apply to contrived examples.

Re: “Clean” code, horrible performance

#336

Post by overgard »

vore wrote: post #15

This guy is so dogmatic about it it hurts. I would argue that clean code is a spectrum from how flexible vs how rigid you want your abstractions to be. If your abstractions are too flexible for good performance, dial them back when you see the issue. If your abstractions are too rigid for your software to be extendable, then introduce indirection. We can all write code that glues a very fixed set of things end to end…

I think part of the problem with supposed "clean" code is that it tends to be a matter of opinion. Is the polymorphic version cleaner than the switch statement version? I would argue the latter is actually easier to read. There's no real reason to think "clean" code is actually clean other than anecdotes and that someone wrote it in a book, but the performance is something that can be objectively measured.

Re: “Clean” code, horrible performance

#338

Post by zX41ZdbW »

You don't have to give up clean code to achieve high performance. The complexity can be isolated and contained.

For example, take a look at ClickHouse codebase: https://github.com/ClickHouse/ClickHouse/

There is all sort of things: leaky abstractions, specializations for optimistic fast paths, dispatching on algorithms based on data distribution, runtime CPU dispatching, etc. Video: https://www.youtube.com/watch?v=ZOZQCQEtrz8

But: it has clean interfaces, virtual calls, factories... And, most importantly - a lot of code comments. And when you have a horrible piece of complexity, it can be isolated into a single file and will annoy you only when you need to edit that part of the project.

Disclaimer. I'm promoting ClickHouse because it deserves that.

Re: “Clean” code, horrible performance

#339

Post by [deleted] »

ilyt wrote: post #249
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…

> 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. CPU meter when clicking anything on "modern" webpage proves that's a lie. Also, sure, even if "clicking on things" is maybe 1-5% vs "looking at things" THAT'S THE…

[deleted]

Re: “Clean” code, horrible performance

#340

Post by rrobukef »

grumpyprole wrote: post #242
sarchertech wrote: post #228

Earlier quoted context omitted.

>Clean code optimizes for improving time-to-market for those features Does it though? Where's the evidence for it? The vast majority of people I've worked with over the last couple decades who like to bring up "clean code", tend towards the wrong abstractions and over abstracting. I almost always prefer working with someone who writes the kind of code Casey was than someone who follows the clean code examples I've sp…

Completely agree. These rules simply do not lead to better outcomes in all cases. Looking at the rules and playing Devil's advocate for fun: > Prefer polymorphism to “if/else” and “switch” Algebraic data types and pattern matching (a more general version of switch), make many types of data transformation far easier to understand and maintain (versus e.g. the visitor pattern which uses adhoc polymorphism). > Code shou…

my 2 cents: I don't see algebraic data types as strictly superiour. It's just the other side of the polymorphic coin: there is open and closed ploymorphism. Open polymorphism happens with interfaces, inheritance, and typeclasses- the number is unlimited. Closed happens with ADTs - an enumeration of the cases.

Open is great for extensibility: libraries can be precompiled, plugins are possible. Changes don't propagate - it is ""forward compatible"" which is great for maintaning the code.

Closed on the other hand is great for matching. Finite is predictable & faster. Finite is self-contained and self-describing because it exposes the data types without shame.

The purpose of the visitor pattern is now clear: it closes the open polymorphism for a finite set. Great, now we only need one kind and we still get matching. Or is it the worst of two worlds? Slow & incomprehensible and all changes propagate everywhere.

So which one is better? Neither. But the reality is that all old imperative languages with polymorphism chose the open kind - the kind that adds more features because it was needed for shared libraries. Leaving you to build any pattern matching yourself and to burn yourself with the unmaintainable code.

If people get burned, they learn. First they say don't do that and only then they replace the gas stove by induction.

Post reply on HN