“Clean” code, horrible performance • Hacker News Board

Re: “Clean” code, horrible performance

#801

Post by mda » Wed, Mar 01, 2023, 3:08 PM UTC

jiggawatts wrote: post #326

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…

> The real situation: a virtual method is called only a few hundred times and is barely visible in profiling tools. The reality is that the entire Java ecosystem revolves around call stacks hundreds of calls deep where most (if not all) of those are virtual calls through an interface. Even in web server scenarios where the user might be "5 milliseconds away", I've seen these overheads add up to the point where it is…

I bet that half an hour startup is not because of nested calls at all. I worked with a ton of Java code and if something is slow, it is usually shitty I/O related code or some algorithmic stupidity, not because of virtual calls and what not.

Re: “Clean” code, horrible performance

#802

Post by _dain_ » Wed, Mar 01, 2023, 3:10 PM UTC

fer wrote: post #6

Unrelated to the content itself, am I the only one wondering if he has his t-shirt mirrored or if he's really skilled at writing right-to-left? Content wise: his examples show such increases because they're extremely tight and CPU-bound loops. Not exactly surprising. While there will be gains in in larger/more complex software by throwing away some maintainability practices (I don't like the term "clean code"), they…

>Just toss a 0.01ms I/O operation in those loops; it will throw the numbers off by a large margin, then one would just rather pick sanity over the speed gains without blinking.

I mean, yes, if you do something completely fucking idiotic like put an IO operation inside a tight calculation loop, then all your speed gains will vanish. But I don't see how that refutes anything.

Re: “Clean” code, horrible performance

#803

Post by badsectoracula » Wed, Mar 01, 2023, 3:15 PM UTC

boredhedgehog wrote: post #635

badsectoracula wrote: post #371

Earlier quoted context omitted.

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 program isn't slow then you don't need to bother making it any faster. But you can only judge that for the very limited set of hardware you personally have access to. You might have many users -- or potential users -- with slower CPUs.

This is where having a target hardware comes in. Aside from doing it for fun, there isn't much of a point to care for 15 year old PCs for example.

Re: “Clean” code, horrible performance

#804

Post by crabbone » Wed, Mar 01, 2023, 3:17 PM UTC

I patiently waited until the end of this video, hoping there'd be a punchline... but, turns out it's one of those C++ selfawarewolves kind of thing.

I mean, dude discovered C++ compiler sucks after over 40 years of trying to make it not suck so much, but ignores the fact that his tools are broken and proceeds to make completely unwarranted conclusions from that.

Needless to mention that software needs to be first and foremost correct. "Clean code" is about reducing the chance of a programmer of making certain kinds of mistakes. And even in the situation where the compiler sucks, it's still worth doing / paying the price in terms of speed, if you can get more confidence of your code doing what it's supposed to. Just like structured programming, "clean code" is an attempt to reduce complexity the author of the code has to deal with.

----

The proper conclusion that should've been the result of his experiments should've been: maybe something went wrong with the language and tools I'm using that even after a massive effort over several generation of programmers and mega-corporations backing that effort, the tools and the language still suck. So, the desirable properties of my programs (i.e. simplicity and ability to be extended) still come at a huge cost.

Re: “Clean” code, horrible performance

#805

Post by badsectoracula » Wed, Mar 01, 2023, 3:17 PM UTC

amelius wrote: post #707

badsectoracula wrote: post #371

Earlier quoted context omitted.

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…

No, if one day you decide to run it on a less capable CPU, it's nice if the optimization work has been done.

This is the same as trying to guess the future that creates "astronautical architecture". You set a target hardware you're willing to support (e.g. PCs released in the last 10-15 years) and anything less is out of scope of the project. You don't need to support 8086 PCs for example.

(ignoring projects made for fun of course)

Re: “Clean” code, horrible performance

#806

Post by badsectoracula » Wed, Mar 01, 2023, 3:19 PM UTC

fvdessen wrote: post #546

badsectoracula wrote: post #371

Earlier quoted context omitted.

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…

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…

> 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'.

No it wont say something like that but if you profile Python itself and see that a lot of time is spent in Python you can get a hint that rewriting it in another language that doesn't have Python's overhead might help.

Re: “Clean” code, horrible performance

#807

Post by frankreyes » Wed, Mar 01, 2023, 3:20 PM UTC

DaiPlusPlus wrote: post #331

frankreyes wrote: post #63

Earlier quoted context omitted.

> 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 f…

Real-world evidence says otherwise

https://stoneridgetechnology.com/company/blog/the-exponentia...

Re: “Clean” code, horrible performance

#808

Post by gnuvince » Wed, Mar 01, 2023, 3:26 PM UTC

t43562 wrote: post #197

One can be tempted to like any assault on "Uncle Bob"'s insulting videos in the light of working on a codebase where every 2nd line forces you to jump somewhere else to understand what it does. That sort of thing generates a rebellious feeling. OTOH the class design lets someone come and add their new shape without needing to change the original code - so it could be part of a library that can be extended and the ind…

That's one side of the expression problem; the other is adding a new operation. With dynamic dispatch, you can add new shapes without altering the others, but if you want to add a new operation (e.g., perimeter()) then you have to modify the base class and all the children. With discriminated unions, adding a new shape requires modifying all the operations, but adding a new operation only requires the creation of a new function.

Re: “Clean” code, horrible performance

#809

Post by nerdponx » Wed, Mar 01, 2023, 3:26 PM UTC

ummonk wrote: post #589

nerdponx wrote: post #451

Earlier quoted context omitted.

But how much of that slowness is due to code that values "cleanliness" excessively? I bet that if you look at the source of nearly any application on your PC, it will be very much not clean on average.

I think it would certainly value the kind of "clean" design patterns (or anti-patterns as I consider most of them) that object-oriented programming evangelists espouse.

Fine, but is that likely to be the cause of these applications generally being slow?

Re: “Clean” code, horrible performance

#810

Post by lysecret » Wed, Mar 01, 2023, 3:40 PM UTC

Well in my experience it is generally true that when you start optimising things get less clean. Let me explain: most of the optimisation situations I had looked like this. Hey this query is pretty slow and costs us quite a bit. Oh look for this type of data it’s super easy we can just return this and then the other rest of the data we can now assume this. So you have broken a single clean and nice case into two slightly less clean but faster cases. And this breaking apart then continues becoming less and less clean because you rely on some obscure characteristic of that specific type of data.