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

161–170 of 191 posts

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

#161

Post by ErroneousBosh »

tcfhgj wrote: post #159
ErroneousBosh wrote: post #144

Earlier quoted context omitted.

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.

> But you're still throwing away so much time on things like bounds-checking memory accesses that never need it. Are you? C++ doesn't check bounds by default, and Rust only checks in certain situations and you could opt out if you wanted to instead of switching to asm

C++ is tremendously bloated though, and wastes hundreds of instructions with stuff you shouldn't need to care about.

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

#162

Post by jdlshore »

alerighi wrote: post #146
TheCoelacanth wrote: post #113

Earlier quoted context omitted.

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.

It doesn’t matter. You’re saving nanoseconds when a db access costs milliseconds. Better to focus on making the code easy to understand and change and focus your effort on optimizing the database.

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

#163

Post by bluefirebrand »

tcfhgj wrote: post #155
bluefirebrand wrote: post #134

Earlier quoted context omitted.

Okay, but Clean Code* would advocate you extract that function to its own class with a new abstraction and it would ultimately wind up way more complicated than the extra params in a function signature

No I wouldn't - keep it short & simple

Nah, you gotta pay attention to what it does, not what it says

Clean Code "says" keep it short and simple but following the advice that Bob lays out does not produce short and simple code

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

#164

Post by zabzonk »

ErroneousBosh wrote: post #161
tcfhgj wrote: post #159

Earlier quoted context omitted.

> But you're still throwing away so much time on things like bounds-checking memory accesses that never need it. Are you? C++ doesn't check bounds by default, and Rust only checks in certain situations and you could opt out if you wanted to instead of switching to asm

C++ is tremendously bloated though, and wastes hundreds of instructions with stuff you shouldn't need to care about.

> stuff you shouldn't need to care about

Such as? I don't believe any C++ compilers are producing extra machine code just for the fun of it.

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

#165

Post by bluGill »

mrkeen wrote: post #107
bluGill wrote: post #31

I stopped reading as soon as I saw the shape class. This example (along with the proverbial animal) has done a lot of harm to OOP and programming. You need base classes (which are not always the right answer, but when they are) to be based on the abstract concept you need to model not something real that is easy to understand when someone isn't an expert in your domain.

Maybe give shape another try. https://www.youtube.com/watch?v=zHiWqnTWsn4 1:00:00 - Open/closed principle and 1:13:52 - Liskov substitution principle. Both are given in terms of Shape, but it's to paint the picture that things are more complicated than you thought, even with something that should have been as simple as shapes. (As opposed to "shapes are easy, just model the world like that and it will be easy too")

I won't have time to watch that anytime soon, but your summary makes my point. The real world is complex and shape as a quick skim shows this article used is just a bad example. Worse they were using this bad example to try to make a general point but the example used was to simple to generalize like that.

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

#166

Post by exe34 »

mattmanser wrote: post #152
giancarlostoro wrote: post #62

Earlier quoted context omitted.

The function size is one rule from Clean Code I disagree with, it's silly. I love helper methods, but use them to a reasonable standard. I'd argue, if you cannot see it all on a 1080p monitor, that it might be getting a bit too long. I read PEP-8 religiously before I learned about "Clean Code" and it helped me to have sane standards in general. Methods that are roughly under 100 lines of code are okay, better is to f…

50-60 lines? You must have tiny text size, on mine, with VS Code, I can see 40 lines. As you get past 30 and your eyesight starts changing, you need to up it. By 45 you need it quite a bit bigger than you used to have it. In the mid-2000s there used to be a lot of articles reminding the mainly young developers that 11-12px font size was unreadable to anyone past 40. On top of that, the default place for a console in…

I always assumed it was wisdom that made functions smaller and the font bigger, but you may be right- it's ageing!

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

#167

Post by wduquette »

brianpan wrote: post #101
wduquette wrote: post #60

Make it work, then make it "clean" (that is, readable and maintainable); then make it fast, and only if measurement indicates that it matters.

Yes! Clean code (which is more readable and maintainable) should be a stop on the way to higher performance code. Otherwise, you are optimizing too early.

To be clear, I greatly disagree with Clean Code’s notion of what constitutes readable and maintainable code.

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

#168

Post by tcfhgj »

zabzonk wrote: post #164
ErroneousBosh wrote: post #161

Earlier quoted context omitted.

C++ is tremendously bloated though, and wastes hundreds of instructions with stuff you shouldn't need to care about.

> stuff you shouldn't need to care about Such as? I don't believe any C++ compilers are producing extra machine code just for the fun of it.

perhaps std::variant https://news.ycombinator.com/item?id=25315225

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

#169

Post by zabzonk »

tcfhgj wrote: post #168
zabzonk wrote: post #164

Earlier quoted context omitted.

> stuff you shouldn't need to care about Such as? I don't believe any C++ compilers are producing extra machine code just for the fun of it.

perhaps std::variant https://news.ycombinator.com/item?id=25315225

> I literally have never found a place where `std::variant` has any positives that can't be written a different, clearer way with drastically better compile time and run time performance.

So, don't use std::variant? To produce performant output from a C++ compiler, you have to make the same sort of informed decisions that you would if you were writing assembler. Possibly not using the standard library at all.

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

#170

Post by win311fwg »

wasmperson wrote: post #63
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…

> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain ba…

> It frames people who don't do "Clean Code" as unprofessional and lazy

Well, isn't that the whole reason for the profession? If you want to be professional and hardworking, why are you instructing a computer to do your work for you? If you aren't being unprofessional and lazy, you're in the wrong business.

Post reply on HN