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

211–220 of 932 posts

Re: “Clean” code, horrible performance

#211

Post by ocimbote »

pocket_cheese wrote: post #189
fredrikholm wrote: post #4

I've worked in projects where no one seemed to know SQL, where massive speed improvements were made by fixing very low hanging fruits like removing select * queries, adding naive indexes, removing N+1 queries etc. Likewise, I've worked in code bases where performance had been dreadful, yet there were no obvious bottlenecks. Little by little, replacing iterators with loops, objects/closures with enum-backed structs/ta…

Could you elaborate what you mean by "naive indexes"?

I assume "naive" means "simple, basic" here. As in "index this column. Period".

Re: “Clean” code, horrible performance

#212

Post by mrkeen »

Tenticles wrote: post #124
sebstefan wrote: post #94

Earlier quoted context omitted.

>I don't find Casey's performant version less readable It does create implicit coupling. If you try to add a new shape you will run into the problem. In the clean code version, your compiler will remind you to implement calculateArea With his version you have to add a new `case` to every switch statement and hope you didn't miss one with a default case, because the compiler won't catch this one. It's a crap way to co…

people using clean code ideologies are being prematurely pessimistic and assuming they know much more about a problem than they actually do when they use these clean code techniques. "I don't know how many shapes I've been asked to do, so I'll assume the worst case scenario and make the code slower and harder than the simple naïve solution that would be hard to read(debatable) if we had one million shapes" is a terri…

> people using clean code ideologies are being prematurely pessimistic and assuming they know much more about a problem than they actually do when they use these clean code techniques.

No. The techniques are there to let you change your codebase as you learn more about the problem.

Re: “Clean” code, horrible performance

#213

Post by jstimpfle »

st3fan wrote: post #149
gjadi wrote: post #131

Earlier quoted context omitted.

I'd say that it really depends on what the code needs to do. For example, if the code is to be distributed and extended as a third-party library, then the class hierarchy is probably a better fit to allow extensibility. But if the purpose of the API is to compute the area of given shapes (as in the example), then it makes sense to make it efficient and there is no use to provide extensibility to the outside world. Th…

> The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. Unfortunately this is just some catchy stereotyping that probably doesn't match reality.

The code examples with the abstract / virtual methods for the most straightforward concepts are a clown show. Not cleanliness but madness.

Re: “Clean” code, horrible performance

#214

Post by Kukumber »

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…

0 responsibility developers

you have Japan infrastructure, and you have Turkey infrastructure

6.1 quake in Japan = nothing destroyed

6.1 quake in Turkey = everything collapses

The engineers in Turkey probably didn't value performance and efficiency

It's the same for developers, you choose your camp wisely, otherwise people will complain at you if they can no longer bear your choice

You act like innocent, but your code choice translate to a cost (higher server bill for your company, higher energy bill for your customers/users, time wasted for everyone, depleting rare materials at a faster rate, growing tech junk)

Selfishness is high in the software industry

We are lucky it's not the same for the HW industry, but it's getting hard for them to hide your incompetence, as more things now run on a battery, and the battery tech is kinda struggling

Good thing is they get to sell more HW since the CPU is "becoming slower" lol

So we now got smartwatches that one need to recharge every damn day

Re: “Clean” code, horrible performance

#215

Post by nimih »

> Our job is to write programs that run well on the hardware that we are given.

The author seems to be neglecting the fact that the whole point of “clean code” is to improve the likelihood of achieving the first goal (code that runs well, i.e. correctly) across months/years of changing requirements and new maintainers. No one (that I’ve ever spoken to or worked with, at least) is under any illusions that you can almost always trade off maintainability for performance.

Admittedly, I think a lot of prescriptions that get made in service of “clean code” are silly or counterproductive, and people who obsess over it as an end unto itself can sometimes be tedious and annoying, but this article is written in such incredible bad faith that its impossible to take seriously.

Re: “Clean” code, horrible performance

#216

Post by PragmaticPulp »

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 local processing time

Unless we’re talking about specific compute-intensive websites, this is almost certainly network loading latency.

Modern web browsers are very fast. Moderns CPUs are very fast. Common, random websites aren’t churning through “multiple seconds” of CPU time just to render.

Re: “Clean” code, horrible performance

#217

Post by AnIdiotOnTheNet »

chpatrick wrote: post #200
AnIdiotOnTheNet wrote: post #187

Earlier quoted context omitted.

> Look, most modern software is spending 99.9% of the time waiting for user input If that's true, why does it take forever to load and frequently fail to keep up with my input?

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, but instead they're working data through a mountain of abstraction layers on the faulty assumption that it is a) saving developers' time, and 2) that that is worth much more than user time.

Re: “Clean” code, horrible performance

#219

Post by xupybd »

>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 one cares how well it runs on the hardware we're given. They care if it solves the business problem. Look at Bitcoin, it burns hardware time as a proof of work. That solves a business problem.

Some programmers work in industries where performance is key but I'd bet not most.

CPU cycles are much cheaper than developer wages.

Re: “Clean” code, horrible performance

#220

Post by Cthulhu_ »

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…

An oft recited of thumb: Make it work, make it pretty, make it fast - in that order. That is, performance bottlenecks are easier to find and fix if your code is clean to begin with.

I sometimes wish performance was an issue in the projects I work with, but if it is, it's on a higher level / architectural level - things like a point-and-click API gateway performing many separate queries to the SAP server in a loop with no short-circuiting mechanism. That's billions of lines of code being executed (I'm guessing) but the performance bottleneck is in how some consultant clicked some things together.

Other than school assignments, I've never had a situation where I ran into performance issues. I've had plenty of situations where I had to deal with poorly written ("unclean") code and spent extra brain cycles trying to make sense of it though.

Post reply on HN