Clean code makes it easier to find high level optimisations which can improve the order of performance, not just shave off a few percent.
From: https://www.computerenhance.com/p/clean-code-horrible-perfor... > The speed differences range from 20-25x — and of course, none of the AVX-optimized code uses anything remotely like “clean” code principles. If clean code limits your default performance to 20 times worse, those high level optimizations might not even be worth it.
“Clean Code, Horrible Performance” Discussion
71–80 of 220 posts
Re: “Clean Code, Horrible Performance” Discussion
#72It 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…
To be fair, this can be said about any technique. Lots of bad code results from people taking a reasonable principle and applying it religiously rather than judiciously.
Re: “Clean Code, Horrible Performance” Discussion
#73For me it is not concept to oppose. You can write optimized code but still name your variables "first_item" instead of u_fp_64_ptr like I often see in "optimized code"
Re: “Clean Code, Horrible Performance” Discussion
#74The dev productivity improvements are questionable.
So let's go do some harm!
(and that example of slow typing in a "big" paragraph is a big red cherry on top of a brown pile!)
Re: “Clean Code, Horrible Performance” Discussion
#75I found it interesting how concrete Casey gets, and how he quickly identified the cause of the UI bug (+ a mitigation). Meanwhile, it looks like Bob was speculating in thin air and throwing out random terms (O(n^2)) trying to fit in.
By “algorithm” I’m referring to more than just asymptotic complexity. Even so, as for “O(n^2)”… well, I didn’t analyze the code myself, but judging by Casey’s analysis (or even just by the symptoms), it seems quite likely that the time taken to input a character is at least O(n) in the number of characters entered so far (if not worse). That makes the total operation of entering n characters take O(n^2) time. Bob does seem to be referring to the total being O(n^2) rather than each character being O(n^2), since the reallocation strategy he mentioned as an example would similarly take O(n) per character. In that context, O(n^2) is less of a guess, more of a reasonable assumption given the observed performance characteristics. And it’s a reasonable aspect to point a finger at, because lowering the asymptotic complexity would be an essential part of fixing the performance problem. Not sufficient by itself, but pretty much necessary.
Re: “Clean Code, Horrible Performance” Discussion
#76Architecture wise, the Clean Architecture is a good starting point, I would enforce one or two rules - maybe domain seperation and business logic/driver seperation, but not go more zealous then that.
Re: “Clean Code, Horrible Performance” Discussion
#77It 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…
So many times I've seen a more readable, simpler code turned out to be more efficient as well. In other words, if it's easy for the CPU to read, it's probably going to be easy for a human too. They both stumble a little on indirection and jumping around. The other advantage of simple (macro-level, and not "one line functions" micro-level simplicity) code is that it also tends to have fewer bugs, and what bugs do appe…
Here are my thoughts in a bit more detail from a previous thread: https://news.ycombinator.com/item?id=35061151
Re: “Clean Code, Horrible Performance” Discussion
#78Earlier quoted context omitted.
Strong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.
Hm... Ad hominem, truism, truism, ad hominem. And not even disagreeing with the conclusion in the end...
Re: “Clean Code, Horrible Performance” Discussion
#79I'm starting to hate programming discussions, after you've read a lot of them they're predictable, boring as hell and you can argue endlessly just because you value a little bit different things. This discussions is yet another, nothing special way of saying: context matters. You have a list of requirements of what you want to achieve, some of them do appear during development and you develop against this. I have com…
you've probably never worked in an average enterprise java shop. The religious refactoring of any kind of software to its most generic and decoupled design, under the name of "cleanliness", is quite impressive. it's quite important that one of the most well known figure recognize that those designs have costs in terms of performance and are not suitable anywhere.
Re: “Clean Code, Horrible Performance” Discussion
#80For me it is not concept to oppose. You can write optimized code but still name your variables "first_item" instead of u_fp_64_ptr like I often see in "optimized code"
When code needs to be heavily optimized, the fact that some variable is a pointer to a 64bit unsigned floating point number may well be more relevant for understanding the code than the fact that it points to the first item in some list.