Live data from Hacker News

“Clean Code, Horrible Performance” Discussion

github.com

71–80 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#71
post #4

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.

If your performance-critical code is 25x slower than it could be, while using the same algorithm, it’s not “clean”, it’s just bad.

Re: “Clean Code, Horrible Performance” Discussion

#72
post #8

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

> I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise.

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

#73
post #46

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

Re: “Clean Code, Horrible Performance” Discussion

#75

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

But Bob was right that the problem was algorithmic. Checking whether a string ends with a prefix of an emoji abbreviation is a task that could easily be done in a microsecond. It’s apparently taking 100 milliseconds, which is 100,000 times slower. Even factoring in the overhead of JavaScript, you could easily add a 10x or 100x “clean code” penalty and still be nowhere near the level where it’s a performance problem – if the algorithm is correct.

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

#76
Enterprise Code should be concerned with getting the best "order" of performance (i.e. O(n) over O(n^2)), but beyond that design for brevity and clarity.

Architecture 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

#77
post #8

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

So why don’t we write plain old assembly then, ad absurdum?

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

#78
post #62

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

[deleted]

Re: “Clean Code, Horrible Performance” Discussion

#79
post #50

I'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.

That hasn’t been generally true for more than a decade. Where they still do it, they just have a shitty architect, and can and do happen regardless of tech stack.

Re: “Clean Code, Horrible Performance” Discussion

#80
post #46

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

But that is explicitly known by the type, we are not writing 90s era microsoft office (hungarian notation really should not be used).
Post reply on HN