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

51–60 of 192 posts

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

#51

Post by tialaramex »

bluGill wrote: post #28
general1465 wrote: post #20

Earlier quoted context omitted.

> Functions should be small + Functions should do one thing This is often a trap for performance. Sure, it looks nice on a screen but calling a function to return a variable is usually epic waste of performance unless compiler will save you by inlining the function into your code or architecture you are using has a magic instruction for that (call vs fcall - which compiler has to recognize and use) which is just fanc…

If your compilers is any good it will inline, and do a better job than you of figuring out what should be inlined. For that matter function calls are generally fast so long as the objects you copy as part of the function call are not slow to copy (which they can be). There are exceptions to the above, but in general small functions are not a problem. What is a problem is large functions. I have seen functions that we…

Manual inlining, like manual loop unrolling wants an explanation, why did you do this, why not let the compiler do it? If I see it with no explanation I am going to assume you don't know what you're doing.

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

#52

Post by rbanffy »

fellowniusmonk wrote: post #37
rbanffy wrote: post #34

Earlier quoted context omitted.

> The problem with a long function is not if it has N or N+1 lines of code, it's that length code with many branching conditions is prone to be untestable and introduce non trivial bugs. Once you start to refactor, not only is it easier to parse but harder to break. This fact is known for decades now. A function with too many lines is, most likely, doing more than one thing. Functions should do one thing, be easy to…

I once saw a professional software engineer try to refactor the spaghetti code in a complex bioinfomactics project written in python. It was a complete failure. That branch was abandoned and development continued off the spaghetti. There is a reason bioinformatics has its own set of viz charts that only they use. That's my anecdote anyway, it led me to the conclusion that sometimes things are continuous spaghetti and…

> It was a complete failure. That branch was abandoned and development continued off the spaghetti.

It was considered too hard, most likely because the present state of the code already degenerated beyond recovery. It might be difficult, but it's never impossible.

> Mapping to terrain is always the real effort in my opinion.

Yes. The domain might be complex, and it might be possible that there are no simple ways to work within that domain. Irreducible complexity is, after all, a thing.

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

#53

Post by rbanffy »

Jtsummers wrote: post #48
rbanffy wrote: post #43

Earlier quoted context omitted.

> I have seen functions that were over 60,000 lines long That can't possibly be from a serious person.

I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran, so it wouldn't surprise me if people created ones as big as bluGill describes. The C was almost always written by EEs who learned that function calls were expensive and so they minimized their use of them (this was their stated rationale, not me guessing). What amused me was that every time I tackled one of those things I'd reduce…

> I've seen 10k+ SLOC functions written in C, and 20k SLOC functions written in Fortran,

That, spoken by Rutger Hauer.

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

#54

Post by tcfhgj »

tranceylc wrote: post #49
tcfhgj wrote: post #40

Earlier quoted context omitted.

[flagged]

Even the author of clean code would fall under someone who can’t program

what?

I am talking about knowing the idea of clean code, which doesn't include dogmatically limiting #locs in functions to an arbitrary number.

So if someone hates clean code for someone doing that, it's just dumb.

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

#55

Post by the__alchemist »

locknitpicker wrote: post #22
Aurornis wrote: post #12

I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…

[flagged]

It sounds like we have opposite programming styles!

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

#57

Post by jackling »

glitchc wrote: post #36

I'm not sure I follow the thrust of the article. The author starts off with talking about clean code, but then compares OO with procedural code. It's not the same thing, and of course we've always known that OO abstractions carry a performance penalty. Even the founders of OO (Alan Kay et al.) acknowledged the memory and compute impact, but thought it was a worthwhile tradeoff for clean abstractions in complex code-b…

He states at the start of the article the tenets of clean code he's arguing against, not just the general OOP of it. Shows how ignoring a certain tenet leads to increase performance, that's the thrust of the article. He routinely in the article goes back to the tenets he's arguing against.

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

#58

Post by wduquette »

jackling wrote: post #38
taybin wrote: post #19

Yes, a toy problem only needs a simple implementation. This is a straw man. And I don't even like Robert Martin's Clean Code, but the author is not addressing where this style actually provides benefits. When you're updating 23 if-statements because you had to add support for some new business workflow, you'll wish you had a conceptual entity that encapsulated the operations on the type of workflows so you just had t…

It's a problem chosen by the author of Clean Code. How is it a strawman? The author of the article is directly refuting the style of the problem/solution that the original author chose, and arguably demonstrated a better approach. That is not a strawman.

Using `switch` is not a better approach if the design allows for outsiders to add their own shapes at a later time. Using `switch` probably is a better approach if the range is shapes is fixed and new shapes can't be added, especially if the language's `switch` statement requires that all valid cases be included.

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

#59

Post by wing-_-nuts »

Aurornis wrote: post #12

I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…

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