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

181–190 of 192 posts

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

#181

Post by 9rx »

RaftPeople wrote: post #178
antonymoose wrote: post #171

Earlier quoted context omitted.

I would charitably say that it’s a function of a different time and place in programming. The way you write “Clean COBOL,” “Clean Java 6/J2EE,” and “Clean Rust” are all going to be very different. There is still good meat-on-the-bone in the book, and especially interesting if you’re working in a legacy system from that older time and place.

> I would charitably say that it’s a function of a different time and place in programming. I really think it was just one persons opinion that got published. I started in the 80's and at each software company I worked at they had standard styles that I think we're very clean and organized without being overly dogmatic in any one direction.

> I really think it was just one persons opinion that got published.

What alternative is there? Obviously very few of the ideas in the book were conceived of by Uncle Bob himself, but his editorial opinion is what chose which ideas to include. If that weren't the case, his name wouldn't be on the book.

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

#182

Post by bsoles »

Scubabear68 wrote: post #118
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…

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

This comment cannot be overstated. Armchair "software engineers" like them do a lot of disservice to the community by promoting non-workable solutions in real production environments.

On the other side, I still consider McConnell's Code Complete to be a gem.

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

#183

Post by chocrates »

Gibbon1 wrote: post #153
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…

I keep coming back to the idea he's advocating using long function names as a substitute for comments. Instead of // do the thing followed by 5 lines of code to do the thing. You're supposed to put those five lines in a function named DoTheThing(). That doesn't seem better to me.

I like function names like that. If your function name is obnoxiously long then you might be doing too much in your function.

I'm a bad programmer though and nothing I do is particularly important enough to optimize.

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

#184

Post by josephg »

TheCoelacanth wrote: post #177
josephg wrote: post #116

Earlier quoted context omitted.

This is only true up to some point of skill & complexity. Hotspot optimisation only takes you so far. Eventually you can end up with a program that is fast everywhere but which is still somehow slow at the macro level. Like LLVM. Truly fast software is made by thinking about data flow from the start. If you use the right data structures, the code takes care of itself. But this is far beyond Clean Code. The examples i…

Choosing the right data structure isn't in opposition to making simple, readable code; it's part of it. Nothing over-complicates code more than a bad choice of data structure. If you pick the data structure that simplifies your code the most, the vast majority of the time that is also the right choice for performance. I disagree with much of the advice in Clean Code, but it has nothing to do with performance. Clean C…

If you go with simple, straightforward data structures you often get adequate performance at the macro level. In my experience, getting really good performance often involves being clever with data structures. It depends how far you want to push performance.

I’ve done a lot of work optimising text CRDTs. There, the simple data structure is (essentially) a list which contains metadata for each character. But you’re constantly scanning and inserting into the list. You can improve it in two ways: first, make each list item store the metadata for a connected span of characters. Second, use a b-tree for fast insertion. Make the b-tree store aggregate metadata in internal nodes. That gets you orders of magnitude better performance - O(n) per keystroke to O(log n). RLE gets ~10x lower ram utilisation. It’s only the obvious data structure when you’ve thought about the problem a lot. And you have to write your own btree - there are no libraries for this. At least, none I have found.

> I'm saying that you shouldn't sacrifice simplicity and readability for the sake of performance until you are sure it's necessary

It really depends on the domain. If you’re making a note taking app, you probably get good enough performance by doing the obvious thing. If you’re making a browser, database, llm inference engine or 3d game engine, it pays to think about perf from the start. But my impression is that most people on this site aren’t doing that sort of thing.

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

#185

Post by zeratax »

jdlshore wrote: post #162
alerighi wrote: post #146

Earlier quoted context omitted.

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.

you are hyperfocusing on a single example. there are contexts where it matters and others where it doesnt sure, but i dont think either approach is inherently easier to understand or maintain

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

#186

Post by zeratax »

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…

the argument that it's more maintainable seems to never be grounded in much of anything though in my experience

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

#187

Post by TheCoelacanth »

zeratax wrote: post #185
jdlshore wrote: post #162

Earlier quoted context omitted.

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.

you are hyperfocusing on a single example. there are contexts where it matters and others where it doesnt sure, but i dont think either approach is inherently easier to understand or maintain

The only context where the overhead of a virtual function call matters is in tight inner loops.

That's by far the easiest place to apply the "write something simple and readable and then measure and see if you need to change it" approach, so it just plainly doesn't work as argument against that approach.

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

#188

Post by TheCoelacanth »

josephg wrote: post #184
TheCoelacanth wrote: post #177

Earlier quoted context omitted.

Choosing the right data structure isn't in opposition to making simple, readable code; it's part of it. Nothing over-complicates code more than a bad choice of data structure. If you pick the data structure that simplifies your code the most, the vast majority of the time that is also the right choice for performance. I disagree with much of the advice in Clean Code, but it has nothing to do with performance. Clean C…

If you go with simple, straightforward data structures you often get adequate performance at the macro level. In my experience, getting really good performance often involves being clever with data structures. It depends how far you want to push performance. I’ve done a lot of work optimising text CRDTs. There, the simple data structure is (essentially) a list which contains metadata for each character. But you’re co…

That seems like a pretty niche problem. There are already numerous high quality browsers, databases, llm inference engines and 3d game engines and only a tiny portion of devs are working on that type of thing.

The vast majority of applications are better off using one of the many high-performance, battle-tested implementations of b-trees that already exist, which, for users of those implementations, is one of the simplest and most commonly used data structures; we just call them databases and filesystems instead of b-trees.

Every rule has exceptions but you should know the rules before you decide to break them. For anyone other than an experienced expert, writing your own b-tree implementation in a production system is an extremely foolish decision (if it's for fun or learning, do whatever you want).

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

#189

Post by josephg »

TheCoelacanth wrote: post #188
josephg wrote: post #184

Earlier quoted context omitted.

If you go with simple, straightforward data structures you often get adequate performance at the macro level. In my experience, getting really good performance often involves being clever with data structures. It depends how far you want to push performance. I’ve done a lot of work optimising text CRDTs. There, the simple data structure is (essentially) a list which contains metadata for each character. But you’re co…

That seems like a pretty niche problem. There are already numerous high quality browsers, databases, llm inference engines and 3d game engines and only a tiny portion of devs are working on that type of thing. The vast majority of applications are better off using one of the many high-performance, battle-tested implementations of b-trees that already exist, which, for users of those implementations, is one of the sim…

There are already numerous iOS apps and numerous websites. And yet, people keep making more!

I think I broadly agree with your overall point. I’ve just spent a lot of my career working on niche problems like this. And there are a lot of people working on systems software. Windows, Linux, macOS, chrome, postgres, etc don’t write themselves. But unless you move in those circles, you can spend your whole life never interacting with any of those engineers.

> we just call them databases and filesystems instead of b-trees.

The b-trees I’m talking about are in memory. Btrees often outperform other kinds of in memory tree structures (avl, rb, binary, etc) because you get fewer dram memory stalls.

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

#190

Post by TheCoelacanth »

josephg wrote: post #189
TheCoelacanth wrote: post #188

Earlier quoted context omitted.

That seems like a pretty niche problem. There are already numerous high quality browsers, databases, llm inference engines and 3d game engines and only a tiny portion of devs are working on that type of thing. The vast majority of applications are better off using one of the many high-performance, battle-tested implementations of b-trees that already exist, which, for users of those implementations, is one of the sim…

There are already numerous iOS apps and numerous websites. And yet, people keep making more! I think I broadly agree with your overall point. I’ve just spent a lot of my career working on niche problems like this. And there are a lot of people working on systems software. Windows, Linux, macOS, chrome, postgres, etc don’t write themselves. But unless you move in those circles, you can spend your whole life never inte…

I'm not disagreeing that there are cases where it makes sense to implement a b-tree; I don't think there are any cases where it makes sense to implement a b-tree (in production) as a person who needs beginner-level advice about code organization.
Post reply on HN