“Clean” code, horrible performance • Hacker News Board

Re: “Clean” code, horrible performance

#241

Post by bob1029 » Tue, Feb 28, 2023, 9:47 PM UTC

kaba0 wrote: post #166

MikeCampo wrote: post #158

Earlier quoted context omitted.

Just because you haven't been exposed this issue doesn't mean it doesn't exist. "the real situation", "no one", "in real projects", "never pop up"...give me a break lol.

One can reasonably well guess/know the expected input sizes to their programs. You ain’t (hopefully) loading your whole database into memory, and unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop, that’s just not how most programs look like. If it is, then you should design for it, which may even mean changing programmi…

> unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop

If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board.

We should try to steal more ideas from different domains instead of treating them like entirely isolated universes.

Re: “Clean” code, horrible performance

#242

Post by grumpyprole » Tue, Feb 28, 2023, 9:47 PM UTC

sarchertech wrote: post #228

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…

>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 should not know about the internals of objects it’s working with

This is interpreted by many as "don't expose data types". Actually some data types are safe to expose. We have a JSON library at work where the actual JSON data type is kept abstract and pattern matching cannot be used. This is despite the fact that JSON is a published (and stable) spec and therefore already exposed!

> Functions should be small

"Small" is a strange metric to optimise for, which is why I don't like Perl. Functions should be readable and easy to reason about. Let's optimise for "simple" instead.

> Functions should do one thing

This is not always practical or realistic advice. Most functions in OOP languages are procedures that will likely perform side effects in addition to returning a result (e.g. object methods). Should we also not do logging? :)

> “DRY” - Don’t Repeat Yourself

The cost of any abstraction must be weighed up against the repetition on a case-by-case basis. For example, many languages do not abstract the for-loop and effectively encourage users to write it out over and over again, because they have decided that the cost of abstracting it (internal iteration using higher-order functions) is too high.

Re: “Clean” code, horrible performance

#243

Post by jstimpfle » Tue, Feb 28, 2023, 9:48 PM UTC

morelisp wrote: post #233

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

Accidentally super-linear algorithms happen a lot more when you hide stuff behind three layers of interfaces rather than seeing "oh, this uses a list instead of a set".

True story. And after taking a couple jobs optimizing some messy software modules I've learned to not take those jobs anymore. The only things you can do is throw the crap out of the window and to start afresh with a clean understanding of what we want to achieve. A simple and straightforward solution without BS abstractions is not only much faster but also much less bug-ridden.

Re: “Clean” code, horrible performance

#244

Post by Gluber » Tue, Feb 28, 2023, 9:48 PM UTC

sarchertech wrote: post #228

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…

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

You are confounding three separate skills. Finding the right abstractions is an art, whether you write clean code or not. Writing high performance code is another art.

A really good developer writes clean code using the right abstraction (finding those tends to take the most time and experience) and drop down to a different level of abstraction for high performance areas where it makes sense.

The fact that bad developers suck and write bad code no matter if they use clean code or not does not reflect on the methodology

Re: “Clean” code, horrible performance

#245

Post by CyberDildonics » Tue, Feb 28, 2023, 9:49 PM UTC

gumby wrote: post #171

These days the cost of a programmer is probably a lot greater than the cost of execution, so some of these rules ("prefer polymorphism") are likely worth the tradeoff.

Cost of execution to who? If you don't care about the speed of your program when I execute it, we end up with electron based VPN GUIs that have menus that run at a few frames per second or electron based disk formatters that are a 400 MB download to ultimately run a command line process.

If you don't care about execution speed, I don't want to use it.

Re: “Clean” code, horrible performance

#246

Post by layer8 » Tue, Feb 28, 2023, 9:51 PM UTC

xupybd wrote: post #208

drivers99 wrote: post #184

Earlier quoted context omitted.

It still matters because in your example it will affect how smoothly the computer responds once it gets the user input.

But how much does that matter? If you're scaling to 1000s of users then yes. If you have a GUI for a monthly task that two administrators use, then no. The less something gets used the longer the payback time on the initial development.

You’re not wrong, but today’s software is so slow/high latency so often, despite incredibly powerful hardware, that as a rule it should absolutely matter.

Re: “Clean” code, horrible performance

#247

Post by onion2k » Tue, Feb 28, 2023, 9:51 PM UTC

mquander wrote: post #196

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

For what it's worth, less than 4% of websites use React (approximately 4% use any JS framework) . If you believe the web is slow because of React you are wrong. It's not even due to JS.

Re: “Clean” code, horrible performance

#248

Post by morelisp » Tue, Feb 28, 2023, 9:51 PM UTC

kaba0 wrote: post #166

MikeCampo wrote: post #158

Earlier quoted context omitted.

Just because you haven't been exposed this issue doesn't mean it doesn't exist. "the real situation", "no one", "in real projects", "never pop up"...give me a break lol.

One can reasonably well guess/know the expected input sizes to their programs. You ain’t (hopefully) loading your whole database into memory, and unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop, that’s just not how most programs look like. If it is, then you should design for it, which may even mean changing programmi…

> You ain’t (hopefully) loading your whole database into memory

I've basically built my career for the past decade by pointing out "yes, we can load our whole working set into memory" for the vast majority of problems. This is especially true if you have so little data you think you don't have CPU problems either.

Re: “Clean” code, horrible performance

#249

Post by ilyt » Tue, Feb 28, 2023, 9:52 PM UTC

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 CRITICAL PATH.

Once the app rendered a view obviously it is not doing much but user is also not waiting on anyting and is "being productive", parsing whatever is displayed.

The critical path, the wasted time is the time app takes to render stuff and "but 99% of the time is not doing it" is irrelevant.

Re: “Clean” code, horrible performance

#250

Post by simplotek » Tue, Feb 28, 2023, 9:52 PM UTC

mquander wrote: post #196

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

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...)

You attempted to present an argument that's a textbook example of an hyperbolic fallacy.

There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time".

This blend of specious reasoning is the reason why the first rule of software optimization is "don't". Proponents of mindlessly going about the 1% edge cases fail to understand that the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing, with a tradeoff of producing unmaintainable code.

The truth of the matter is that in 99% of the cases there is absolutely no good reason to run after these relatively large performance improvements if in the end the user notices absolutely nothing. Moreso if you're writing async code that stays far away from any sort of hot path.