“Clean” code, horrible performance • Hacker News Board

Re: “Clean” code, horrible performance

#11

Post by vrnvu » Tue, Feb 28, 2023, 9:01 AM UTC

The problem with the contemporary "clean code" concept is that the narrative that performance and efficiency don't matter has been pushed down the throat of all programmers.

Re-usability, OOP concepts or pure functional style, design patterns, TDD or XP methodologies are the only things that matter... And if you use them you will write "clean code". Even worse, the more concepts and abstractions you apply to your code the better programmer you are!

If you look at the history of programming and classic texts like "the art of programming", "sicp", "the elements of programming"... The concept of "beautiful code" appears a lot. This is an idea that has always existed in our culture. The main difference with the "clean code" cult is that "beautiful code" also used to mean fast and efficient code, efficient algorithms, low memory footprint... On top of the "clean code" concepts of easy to test and re-usable code, modularity... etc

Re: “Clean” code, horrible performance

#12

Post by anonymoushn » Tue, Feb 28, 2023, 9:02 AM UTC

Arnavion wrote: post #9

"Use subclasses over enums" must be some niche advice. I've never heard it. The youtuber seems to be referring to some specific example (he refers to specific advice from "them") so I guess there's some context in the other videos of the series. re: the speedup from moving from subclassing to enums - Compiler isn't pulling its weight if it can't devirtualize in such a simple program. re: the speedup from replacing th…

I think "them" is someone named Robert Cecil Martin, but I'm not sure if this example from the video appears in his book.

What compiler are you using that devirtualizes every class hierarchy? I suspect that Casey is using C++ so he may (unfortunately) have multiple translation units in his program.

Re: “Clean” code, horrible performance

#13

Post by hennell » Tue, Feb 28, 2023, 9:08 AM UTC

I think he's really underplaying the main selling point of clean code - the objective of writing clear maintainable, extendable code. His code was faster, but sometimes how it compares for adding new features or fixing bugs by people new to a code base is where you want to optimize.

Should performance be talked about more? Yes. Does this show valuable performance benifits? Also yes. Is performance where you want to start your focus? In my experience, often no.

I've made things faster by simplifying them down once I've found a solution. I've also made things slower in order to make them more extendable. If you treat clean code like a bible of unbreakable laws you're causing problems, if you treat performance as the be-all-end-all you're also causing problems, just in a different way.

It's given me something to think about, but I wish it was a more fair handed comparison showing the trade offs of each approach.

Re: “Clean” code, horrible performance

#14

Post by mulmboy » Tue, Feb 28, 2023, 9:09 AM UTC

Really enjoyed watching some guy Breathlessly discover data oriented design https://en.wikipedia.org/wiki/Data-oriented_design

there's nothing novel in this video, really nothing to do with clean code. This is same sort of thing you see with pure python versus numpy

Re: “Clean” code, horrible performance

#15

Post by vore » Tue, Feb 28, 2023, 9:11 AM UTC

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 and squeeze every last CPU cycle of performance out of it, but as we all know, software requirements change, and things like polymorphism allow for much better composition of functionality.

Re: “Clean” code, horrible performance

#16

Post by anonymoushn » Tue, Feb 28, 2023, 9:11 AM UTC

hennell wrote: post #13

I think he's really underplaying the main selling point of clean code - the objective of writing clear maintainable, extendable code. His code was faster, but sometimes how it compares for adding new features or fixing bugs by people new to a code base is where you want to optimize. Should performance be talked about more? Yes. Does this show valuable performance benifits? Also yes. Is performance where you want to s…

If someone is new to the codebase, would you rather they need to open a dozen files to see all of the different virtual functions that could occur at one call site, or open one file?

Re: “Clean” code, horrible performance

#17

Post by anonymoushn » Tue, Feb 28, 2023, 9:12 AM UTC

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…

Is there any flexbility tradeoff at all here?

Re: “Clean” code, horrible performance

#18

Post by athanagor2 » Tue, Feb 28, 2023, 9:15 AM UTC

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…

But is it true that "clean code" makes the adaptation to changing requirements easier? I saw a few testimonies saying otherwise.

Re: “Clean” code, horrible performance

#19

Post by vore » Tue, Feb 28, 2023, 9:16 AM UTC

anonymoushn wrote: post #17

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…

Is there any flexbility tradeoff at all here?

The shapes example is pretty contrived so I don't really have an opinion on it either way. But imagine you have something like a File interface and you have implementations of it e.g. DiskFile, NetworkFile, etc., and you anticipate other implementors. Why would you do anything other than have a polymorphic interface?

Re: “Clean” code, horrible performance

#20

Post by 10000truths » Tue, Feb 28, 2023, 9:17 AM UTC

Arnavion wrote: post #9

"Use subclasses over enums" must be some niche advice. I've never heard it. The youtuber seems to be referring to some specific example (he refers to specific advice from "them") so I guess there's some context in the other videos of the series. re: the speedup from moving from subclassing to enums - Compiler isn't pulling its weight if it can't devirtualize in such a simple program. re: the speedup from replacing th…

A compiler can only devirtualize a virtual call if it knows the underlying object’s type at compile time, which it certainly won’t for a runtime populated array of base class pointers.

CSE doesn’t work across function boundaries unless those functions are inlined, which won’t happen with virtual functions due to the above.