Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Clean Code, Horrible Performance” Discussion

github.com

Post reply on HN
Print view View original

111–120 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#111

Post by lozenge »

fwlr wrote: post #59
lazyasciiart wrote: post #51

Earlier quoted context omitted.

> the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead That is a giant presumption.

It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.

There is a lot of inherent complexity there though. Inherently VS needs to support multiple debugging engines and multiple transports to communicate with the debuggee as well (remote vs local debugging). That's OK, two layers of dynamic dispatch is still fast in this context.

Do we update call stack and locals window at the same time, or do we update each one as early as possible but show inconsistent data?

Do we fetch call stack for all stopped threads, or do we wait until the user chooses to focus on a different thread/display all threads using Parallel Stacks windows?

If Watch result is a collection, do we load its members or wait for the user to expand the tree?

If call frame has changed, the strings in Watch need to be re parsed to refer to new variables. Do we do this work every time, or do we optimise for stepping in a single function? Is it worth it if only a few of the debugging engines can support that optimisation?

Each Watch needs to be interpreted in a way that catches all exceptions and creates an error message instead of crashing the debuggee.

If the user puts a breakpoint at the end of a loop and holds down F5, watching the Locals to decide when to switch to stepping, is that a supported use case?

These are the product decisions that lead to the performance, not micro details of how the code was laid out to achieve the goals. I mean, I don't have access to their source code, so I could still be proven wrong. What's an example of a fast debugger?

Re: “Clean Code, Horrible Performance” Discussion

#112

Post by tsimionescu »

kaba0 wrote: post #80
tsimionescu wrote: post #73

Earlier quoted context omitted.

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

The name of a variable is supposed to contain the most relevant information someone needs when looking at an expression. If the most relevant information is the type, then that should be name. The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was.

Imagine you see some code masking the first 40 bits from the location pointed to by first_item. Does the name "first_item" help you understand why they are doing that, or would it be more useful to know that it is the first forty bits of an u_fp_64, so it's masking the mantissa and just keeping the exponent?

Re: “Clean Code, Horrible Performance” Discussion

#113

Post by readlikeasloth »

Last time I checked programming had something to do with computer science. You could say its applied computer science. So I ask myself: how come that this discipline, already 50+ years old, has almost no consensus of how its output aka written code should be structured? Why are there no established standards or rules? Not a rethorical question, happy to hear your thoughts.

Re: “Clean Code, Horrible Performance” Discussion

#114

Post by pkolaczk »

laserlight wrote: post #102
pkolaczk wrote: post #95

Earlier quoted context omitted.

Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.

If you aren't going to use polymorphism to vary behavior, but depend on conditionals, what do you use classes for? Just for hierarchical data encapsulation?

Surprise: I don't use classes. Rust doesn't have them. :P

Re: “Clean Code, Horrible Performance” Discussion

#115

Post by pkolaczk »

goto11 wrote: post #100
pkolaczk wrote: post #95

Earlier quoted context omitted.

Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.

So you are saying context doesn't matter, switch is always better?

If we talk about readability - it is hard to think of a situation when inheritance would be better - it adds an indirection, it hides what's really going on, and at the end of the day the code is also longer and more complex.

However it has some other uses, e.g. when you really want to support adding new cases without modifying the code, e.g when doing a library, you need some kind of polymorphism.

So basically - it is not that abstractions/indirections are inherently bad, but they come at a cognitive cost. And it depends on the context if this cost is justifiable.

Re: “Clean Code, Horrible Performance” Discussion

#116

Post by eviks »

readlikeasloth wrote: post #113

Last time I checked programming had something to do with computer science. You could say its applied computer science. So I ask myself: how come that this discipline, already 50+ years old, has almost no consensus of how its output aka written code should be structured? Why are there no established standards or rules? Not a rethorical question, happy to hear your thoughts.

This confusion is easily resolved - just remove "science"

Re: “Clean Code, Horrible Performance” Discussion

#117

Post by fwlr »

lozenge wrote: post #111
fwlr wrote: post #59

Earlier quoted context omitted.

It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.

There is a lot of inherent complexity there though. Inherently VS needs to support multiple debugging engines and multiple transports to communicate with the debuggee as well (remote vs local debugging). That's OK, two layers of dynamic dispatch is still fast in this context. Do we update call stack and locals window at the same time, or do we update each one as early as possible but show inconsistent data? Do we fet…

>What’s an example of a fast debugger?

My apologies in advance if this feels like a gotcha, but… Casey ended up swapping to RemedyBG for debugging. He made a video about why. From about 0:50 onwards he talks about the speed and feature set of the watch window https://m.youtube.com/watch?v=r9eQth4Q5jg

Also, I don’t mean to be rude by ignoring all the questions you posed; they’re good questions, I just don’t have answers for them (I would hope the developers whose full-time job it is to build debuggers would, though).

Re: “Clean Code, Horrible Performance” Discussion

#118

Post by dsego »

jenadine wrote: post #60
userbinator wrote: post #27

Earlier quoted context omitted.

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…

I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it…

> Many abstraction makes it easier to read for human.

Many abstractions are also conventions, just look at the js/react world. There is redux stores, mobx stores, hooks, class-based components, signals. All different abstractions with various performance and readability concerns. Someone used to one of them would say the others are not readable or maintainable. So maybe we can choose the more performant abstractions and teach them, so it becomes institutional knowledge.

Re: “Clean Code, Horrible Performance” Discussion

#119

Post by SPBS »

pkolaczk wrote: 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…

Thanks, this comment accurately captures my discomfort when reading the parts where Uncle Bob was talking. He consistently portrays Clean Code as a programmer friendliness vs processor speed tradeoff, while my impression of Clean Code has never been that it’s slow and programmer friendly, but full of overengineered design patterns that are horrible to read.“Premature optimisation in code flexibility” is a really succinct way of putting it.

Re: “Clean Code, Horrible Performance” Discussion

#120

Post by dsego »

josephg wrote: post #88
tpoacher wrote: post #84

Earlier quoted context omitted.

Clean code is defined as code that improves programmer efficiency and program readability, eschews premature optimisation by optimising for simplicity, makes code less complex and objectively better by optimising for readability, allowing virtually anyone to safely and easily change it when really needed. So you're actually a clean code proponent. As is usually the case with such debates, it is a debate of differing…

> Clean code is defined as code that improves programmer efficiency and program readability, eschews premature optimisation by optimising for simplicity, makes code less complex and objectively better by optimising for readability, allowing virtually anyone to safely and easily change it when really needed. I think plenty of people love clean code. I love programmer efficiency and readability. But there's clean code…

His examples use class state as faux-global state and dozens of small one-line methods that "do one thing", but don't really, since they operate on this object state. In the end, it makes it difficult to follow the logic flow, since you have to jump around from one small method to the other to understand what's happening. And clear understandable method naming is of limited help, so it turns into this ravioli code anti-pattern, clean on the surface, but semantically all tangled up.
Post reply on HN