“Clean Code, Horrible Performance” Discussion
1–10 of 220 posts
Re: “Clean Code, Horrible Performance” Discussion
#2"constrained problem within a resource constrained environment" is a good phrasing
Re: “Clean Code, Horrible Performance” Discussion
#3this was a very amicable and fruitful discussion
it's been chaffing me a lot last couple of years that it is so hard to learn about making performant code. It was nice of Julia Evans to write that very approachable strace zine [1]. I wished there was more of that kind of stuff. So I am happy Casey is doing a whole course on this stuff [2].
[1] https://wizardzines.com/zines/strace/
[2] https://www.computerenhance.com/p/performance-aware-programm...
Re: “Clean Code, Horrible Performance” Discussion
#4Clean code makes it easier to find high level optimisations which can improve the order of performance, not just shave off a few percent.
Re: “Clean Code, Horrible Performance” Discussion
#5Some gems from the discussion…
> Long ago he wrote a book entitled The Design of Everyday Things. It's well worth the read. Within those pages he stated the following rule of thumb: “If you think something is clever and sophisticated beware -- it is probably self-indulgence.”
> You also asked me "why...". To the extent that I have not answered that above, I'll simply turn the question around and point out that it is probably for the same reason that your video was solely focussed on the amplification of performance to the strident denigration of every other concern. To a performance hammer, everything looks like a nail. ;-)
Overall a very amicable and interesting read.
It’s so easy to preach high level architecture without specifics, but also so very easy to cherry-pick a specific example where generic advice doesn’t apply.
I think it’s interesting that there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” …and I’m absolutely 100% with Uncle Bob that bounded contexts for complex code is the solution.
This is the approach rust takes with unsafe code and it has proved to be an extremely effective principle.
Re: “Clean Code, Horrible Performance” Discussion
#6I’m surprised that such a thoughtful and civil conversation came out of this after the precipitating screed against Clean Code. Kudos to both sides for engaging constructively!
Re: “Clean Code, Horrible Performance” Discussion
#7The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also incredibly important is simply safety.
Today a lot of applications are concurrent, networked, distributed and built in ways where high level or performance impacting features make sense to make sure your program remains in a valid state.
Casey seems to take so much of his advice from his experience on game engines, which are an incredibly forgiving domain in many ways. You can have some bugs, you can drop some things over the network, it doesn't matter much. But you can't really do that in many other applications. If you had a big codebase for an application that is safety critical, going at it with his style of low-level programming you might make some very costly mistakes really quickly.
Re: “Clean Code, Horrible Performance” Discussion
#8It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise.
Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean
The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex and objectively worse in hope it would be easier to extend later. Unfortunately we often dont know how the code will change, and in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears.
IMHO optimizing for simplicity and readability has served me the best. Instead of avoiding the changes in code, it is better to write code so obvious that anyone can safely and easily change it when really needed.
And finally, performance of the program vs performance of the developer is a false dichotomy. So many times I've seen a more readable, simpler code turned out to be more efficient as well. You often can have both.
Re: “Clean Code, Horrible Performance” Discussion
#9At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal.
I watched Casey's video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn't representative of every programming problem.
As an addendum to Casey's video, another popular technique for squeezing more performance is to invert the normal array-of-structs to a struct of arrays, as it tremendously improves SIMD/vectorization. https://en.wikipedia.org/wiki/AoS_and_SoA
For a lot of things that I work on, simply having correct, complete, working code is most of the battle. Execution performance takes a backseat to development time, data acquisition time, human analysis of the problem space and generated output, etc. So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.
Re: “Clean Code, Horrible Performance” Discussion
#10Clean code makes it easier to find high level optimisations which can improve the order of performance, not just shave off a few percent.
It's true. It's easier to make mathematical connections with algebra, combinatorics, etc. when you're reading short formulas and not being not knee-deep in hand-written SSE asm.