Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Clean" Code, Horrible Performance (2023)

computerenhance.com

Post reply on HN
Print view View original

141–150 of 192 posts

Re: "Clean" Code, Horrible Performance (2023)

#141

Post by damienmeur »

It really depends on what you are building, coding is always about trade-offs, and sometimes (not always) you have to choose between maintainability/readability and performance.

If you are writing code for embedded devices where every cpu cycle counts, I would indeed trade a bit of the maintenance for some cpu cycle.

If I am writing a huge web app that has to be maintained years by a large team of devs, I would prefer a more simple/maintanable code over a fast one (+ in such scenarios the real bottlenecks are often your I/O, not the raw CPU perf).

This is for the same reason you usually write code that needs to be fast in low-level programming lng like C and huge web app in Node.js or Java.

Re: "Clean" Code, Horrible Performance (2023)

#142

Post by xnzakg »

nomel wrote: post #124
wren6991 wrote: post #94

Earlier quoted context omitted.

I'm fine with a 1k-line function if you just have that many things to do in a row without taking a breath. Breaking it up into smaller functions feels neater when you write it, but when I read it I'm essentially just macro-expanding it in my brain into the original 1k linear version, and that has some cognitive overhead (especially when they end up misordered in the file, or split across different files). I also have…

I've heard this called "lasagna code". I've definitely drifted towards longer code, if nothing in that function is used elsewhere. Some tasks really are just lists of things to do (especially in something like image processing), and I think that sometimes it doesn't make sense to put lists of lists in your list of things to do.

But in many cases, you could split it up into smaller, `inline` functions.

Re: "Clean" Code, Horrible Performance (2023)

#143

Post by captainbland »

jeffnash wrote: post #77

It seems like the main takeaway is that many textbook OO paradigms aren't the most optimized representations of the code. In this case, the cost is dynamic dispatch and pointer-chasing. This is a function of the Shape abstraction, but not the abstraction itself. But the argument is you're trading some of that performance optimization for maintainability. None of this is exactly news. And while I'm here ranting: I nev…

I think single dynamic dispatch is one thing but ends up reasonably well optimised by modern compilers, especially the JVM. I think most code written since the 2010s prefers the composition over inheritance pattern for the most part so tends to use interfaces rather than concrete base classes.

That said, double dispatch as in the visitor pattern is often too hard to analyse for optimisation and I think humans frequently get a bit lost with it as well. Fortunately pattern matching is doing away with it. I think it's one of these gang of four patterns that has a lot of people scratching their heads and wondering if the open/closed principal is that worth sticking to if this is the outcome.

Re: "Clean" Code, Horrible Performance (2023)

#144

Post by ErroneousBosh »

zabzonk wrote: post #106
ErroneousBosh wrote: post #82

This is just bloody stupid. If you care about performance, you don't use OOP, you don't use if/else, you don't use switch{case}, what you do is you write the hot parts in assembler. If you aren't writing it in assembler, you're writing slow code. But that code is still not optimised until you've implemented it in an ASIC.

> If you aren't writing it in assembler, you're writing slow code. Depends in part in how good you are at writing assembler.

True, with modern processors there is a hell of a lot of "it has to be this way round for the pipeline to flow" that the compiler does for you.

But you're still throwing away so much time on things like bounds-checking memory accesses that never need it.

Re: "Clean" Code, Horrible Performance (2023)

#145

Post by Someone »

jeltz wrote: post #61
wing-_-nuts wrote: post #59

Earlier quoted context omitted.

My personal benchmark for 'maybe this function is too long' is when it doesn't fit on the page.

I don't think any such benchmark should exist. As long as the function only does one thing there is no upper limit. Artificially splitting a large function only reduces readsbility. What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. I personally write quite short functions b…

> I don’t think any such benchmark should exist.

wing-_-nuts says (emphasis added) “My personal benchmark for 'MAYBE this function is too long' is when it doesn't fit on the page.”.

I think that’s a fine heuristic. Long functions can be fine, but longer functions tend to be less testable, so you should try to avoid them.

On the other hand, it can take lots of thinking to properly decompose functionality, and that decomposition can easily change when requirements change, so spending that time may not be worth it.

Re: "Clean" Code, Horrible Performance (2023)

#146

Post by alerighi »

TheCoelacanth wrote: post #113
philippta wrote: post #87

Earlier quoted context omitted.

> There are surely cases where having an interface as an abstraction and multiple implementations makes sense. I think most people aren't aware of the alternative, which is: A function that can call different implementations based on some other variable. E.g. instead of having RealDB and MockDB type have a createUser() (method), you have a createUser() (function) that switches part of it's logic based on what DB is s…

Yes, but there's not a chance that there's a material difference in performance between those options because of virtual functions. Unless you're doing something really stupid, nothing other than the DB access is going to be worth optimizing. If those two options are accessing the DB in exactly the same way, then they will probably be within 1% of each other in performance.

Depends, for example if the variable that selects between the two implementations is a compile time constant (#define or constexpr variable) the compiler can really remove the conditional and all the code of the choice that is not always selected leading to higher performance and smaller footprint.

Re: "Clean" Code, Horrible Performance (2023)

#147

Post by nixon_why69 »

bheadmaster wrote: post #138
Scubabear68 wrote: post #118

Earlier quoted context omitted.

The ugly reality is consultants like Martin have little production coding experience. Martin has posts going back to the early 90s showing he had little understanding of how software teams work and deliver value. From what I have seen, his ideas were formed in a vacuum divorced from real coding. You can see it in the small amounts of open source he has released. The kind of guy who will always prefer 50 classes to 5.…

Those who can't do, teach.

I hate that phrase. There are billions of people who can't code and also aren't teaching it. And plenty of people who are good at something and enjoy giving back and sharing in the form of teaching.

Re: "Clean" Code, Horrible Performance (2023)

#148

Post by rbanffy »

bluGill wrote: post #105
rbanffy wrote: post #103

Earlier quoted context omitted.

I’m not sure the author knew what was happening. It seems like it worked like this and they left it at that.

While this was the worst example he constantly wrote code like that. He could write code like that with few bugs faster than any other programmer I've ever worked with could write code. Management changed between loving and hating him, they knew what his code cost, but they also knew they were getting results fast when that mattered.

I knew a guy who naturally wrote code that baffled me all the time. Sometimes I wondered how the compiler managed to figure it out.

Fun thing: he was like that all the time - it felt like his language cortex was just wired differently.

Re: "Clean" Code, Horrible Performance (2023)

#149

Post by rbanffy »

ryanbrunner wrote: post #112
rbanffy wrote: post #104

Earlier quoted context omitted.

> "Functions should be 5 lines or less" This can’t really be a serious guideline unless you are writing APL, in which 5 lines can already be daunting to grasp. This guidance depends on the language. For Python, once you get over 50 lines it starts to look like you don’t actually know what you are doing anymore.

Sorry, you're right - 20 lines or less is the recommendation in the actual text of Clean Code. I have seen people try to push that down to 5 in Ruby on Rails development (IIRC, the most popular linter at one time tried to enforce 5 lines) In any case, the point stands - there are 19 line functions that are too sense, and 21 line functions that are sensible.

A hard boundary should only emit a warning. The same with nested loops and ifs.

Re: "Clean" Code, Horrible Performance (2023)

#150

Post by josephg »

saidnooneever wrote: post #135
josephg wrote: post #109

Earlier quoted context omitted.

I just think - in the book at least - he has really bad taste. The examples are full of “spooky action at a distance”. He writes the exact sort of class functions that make a lot of OO terrible to work with, where a function that should be pure has some weird hidden side effects. Code like that is really difficult to reason about and impossible to reuse safely. Somewhat ironic, given what he preaches in the rest of t…

your opinion is no less valid than his. you see the problem if you use the word clean or beautiful. its opinions. so people will debate it till no end. it matters nothing at all.

I don't think beauty in code is entirely subjective. Beautiful code is like beautiful mathematics. Simple, clean, and correct by construction. All at once. There's plenty of ways to implement a graphics engine, web browser, database or OS kernel. Some of them are simpler, faster and more correct. And some approaches will inexorably lead you to a bug ridden mess.

You see this clearly if you ever teach. I would give all my students the same spec. Some students submitted small, simple programs which passed all the tests with flying colours. Some students would submit huge programs which barely worked.

As Alan Kay said once, the right point of view (on a problem) is worth 50 IQ points. At the margins there's subjectivity and tradeoffs. But lots of programs are more or - more often - much less beautiful.

Post reply on HN