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

41–50 of 192 posts

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

#41

Post by alerighi »

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…

Indeed. The problem is trying to apply the principles of "Clean Code" or more generally of OOP everywhere. There are surely cases where having an interface as an abstraction and multiple implementations makes sense. There are case where it doesn't, and if you take as a dogma "everything shall be the implementation of an interface" you get more complex code and performance penalty for nothing.

There is nothing wrong with having procedural code with a switch case, as there is nothing wrong in having global variables, in having even goto, depends on how you use it.

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

#42

Post by rbanffy »

general1465 wrote: post #20
flossly wrote: post #5

I'd say Clean Code is teaching many bad-practices. Too many to be recommended.

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

> unless compiler will save you by inlining the function into your code or architecture

That's precisely what a compiler should do. Your code should be easy to read and understand. Let the compiler inline calls and unroll loops (until the I1/L2/L3 cache starts becoming a problem, that is)

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

#43

Post by rbanffy »

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…

> I have seen functions that were over 60,000 lines long

That can't possibly be from a serious person.

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

#44

Post by kelseyfrog »

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]

Clean code nitpickers mistake the map for the territory. The rules are the map, maintainability is the territory. The map is a model of the territory, but the territory always contains more detail, both zones of maintainability not covered by the rules and zones of unmaintainability covered by the rules. The rules are heuristics, and like all heuristics, they have false positives and false negatives. Being a mature developer means knowing the limits of tools including processes, style, and standards. When they nit to the rules and not to the goal, it doesn't contribute, it distracts.

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

#45

Post by [deleted] »

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]

[deleted]

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

#46

Post by tcfhgj »

alerighi wrote: post #41
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…

Indeed. The problem is trying to apply the principles of "Clean Code" or more generally of OOP everywhere. There are surely cases where having an interface as an abstraction and multiple implementations makes sense. There are case where it doesn't, and if you take as a dogma "everything shall be the implementation of an interface" you get more complex code and performance penalty for nothing. There is nothing wrong w…

The principle of clean code includes KISS, therefore complex code for nothing isn't clean code

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

#47

Post by jackling »

HeavyStorm wrote: post #26
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…

Thank you! I always see this stupid conversation about performance and nobody seems to get this.

> stupid conversation about performance

The article is titled "'Clean' Code, Horrible Performance", that's the argument being made. Why is it a stupid conversation? If you think the trade-offs are necessary, then fine, argue that. But that doesn't change the objective measures that the author did to demonstrate the thesis of article.

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

#48

Post by Jtsummers »

rbanffy wrote: post #43
bluGill wrote: post #28

Earlier quoted context omitted.

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…

> 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 the line count by 70-90%, and usually at least double performance, by using a bunch of small functions to encapsulate the repeated logic. Compilers inline well, and have for quite some time.

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

#49

Post by tranceylc »

tcfhgj wrote: post #40
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]

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

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

#50

Post by scelerat »

How much of the performance differences come down to language or compiler choice in these examples?

Would I see the same kinds of performance gains or losses avoiding or using certain patterns in Go or Rust or Java? Are they the same examples as in C++?

What about dynamic languages like ruby or python or javascript?

Post reply on HN