These days the cost of a programmer is probably a lot greater than the cost of execution, so some of these rules ("prefer polymorphism") are likely worth the tradeoff.
“Clean” code, horrible performance
171–180 of 932 posts
Re: “Clean” code, horrible performance
#172There's a tradeoff. Engineering time is expensive. Machine time can be expensive too. We need to optimize these costs by making most code that's not performance relevant easy to read and then optimize performance critical code paths while hiding optimization complexity behind abstractions. Either extreme is not helpful as a blanket method.
Re: “Clean” code, horrible performance
#173Two years ago I was subjected to NDepend: A clean-code checker and enforcer.
Their tool was so dog slow I could see it paint the screen on a modern computer.
I rejoiced when we yanked it out of our toolchain. Most of the advice that it gave was unambiguously wrong.
Re: “Clean” code, horrible performance
#174There is no doubting Casey's chops when he talks about performance, but as someone who has spent many hours watching (and enjoying!) his videos, as he stares puzzled at compiler errors, scrolls up and down endlessly at code he no longer remembers writing, and then - when it finally does compile - immediately has to dig into the debugger to work out something else that's gone wrong, I suspect the real answer to progra…
When working with a larger code base, there will always be parts that you don't remember writing and you'll inevitably have to read the code to understand it. That's just part of the job/task, regardless of the style it's written in.
In shared code particularly with a culture of refactoring, there's no guarantee that the function call you see is doing what you remember it doing a year ago.
When I was coming up I got gifted a bunch of modules at several jobs because the original writer couldn't be arsed to keep up with the many incremental changes I'd been making. They had a mentality that code was meant to be memorized instead of explored, and I was just beginning to understand code exploration from a writer's perspective. So they were both on the wrong side of history and the wrong side of me. Fuck it, if you want it so much, kid, it's yours now. Good luck.
Re: “Clean” code, horrible performance
#175Most programming tends to decompose doing an operation for each element in a sequence into implementing the operation for a single element and then doing that repeatedly in a loop.
This is obviously wrong for performance reasons, as operations tend to have high latency but multiple of them can run in parallel, so many optimizations are possible if you target bandwidth instead.
There are many languages (and libraries) that are array-based though, and which translate somewhat better to how number crunching can be done fast, while still offering pleasant high-level interfaces.
Re: “Clean” code, horrible performance
#176Earlier quoted context omitted.
If you have more than one person working on a codebase; clean code matters a lot. A code base that can't be understood and maintained by the whole team, will degrade quickly.
> If you have more than one person working on a codebase; clean code matters a lot. You can have fast and clean code, just not the Uncle Bob style of "clean code". Uncle Bob hijacked the meaning of cleanliness. It doesn't mean that code written like that is actually clean, in fact it's usually the opposite: Uncle Bob's clean code is NOT clean.
It's also worth noting that Bob's advice is for Java, which has relatively unusual performance-idiosyncrasies around polymorphism and function calls. Much of the advice becomes very poor in languages that aren't JVM-based.
Re: “Clean” code, horrible performance
#177Earlier quoted context omitted.
> I see your point, but no one uses Windows notepad for coding anymore. Did I miss an IDE that inlines all those things for you automatically? Because ones that only give you a "jump to definition", or maybe a one-at-a-time preview in a context popup, are not much better than Notepad++. You still don't get to see all the relevant things at the same time.
Most real world applications won’t have `print “red”` or the like under a specific implementation. Good luck inlining 6 1000 lines-implementations into a single switch statement.
The "project" vs. "external" vs. "system" library conceptual distinction exists for a reason. But of course you want presentation-level inlining to be semi-automated, much like autocomplete and jump to definition.
Re: “Clean” code, horrible performance
#178This guy is so dogmatic about it it hurts. I would argue that clean code is a spectrum from how flexible vs how rigid you want your abstractions to be. If your abstractions are too flexible for good performance, dial them back when you see the issue. If your abstractions are too rigid for your software to be extendable, then introduce indirection. We can all write code that glues a very fixed set of things end to end…
Spectrum or I believe more of a Venn Diagram.
There was a moment in grade school where I was sat down and it was explained to me that you don't have to take a test in order. You can skip around if you want to, and I ran so far with that notion that at 25 I probably should have written a book on how to take tests, while I could still remember most of it.
One of the few other "lightning bolt out of the blue" experiences I can recall was realizing that some code constructs are easier for both the human and the compiler to understand. You can by sympathetic to both instead of compromising. They both have a fundamental problem around how many concepts they can juggle at the exact same time. For any given commit message or PR you can adjust your reasoning for whichever stick the reviewer has up their butt about justifying code changes.
Re: “Clean” code, horrible performance
#179I think the author is taking general advice and applying it to a niche situation.
> So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape
Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high performance calculation software then sure, go crazy, get those improvements.
But most of us aren't doing that. Most developers are doing work where the biggest problem is adding the next umpteenth features that Product has planned (but hasn't told us about yet). Clean code optimizes for improving time-to-market for those features, and not for the CPU doing less work.
Re: “Clean” code, horrible performance
#180Earlier quoted context omitted.
Is there any flexbility tradeoff at all here?
The shapes example is pretty contrived so I don't really have an opinion on it either way. But imagine you have something like a File interface and you have implementations of it e.g. DiskFile, NetworkFile, etc., and you anticipate other implementors. Why would you do anything other than have a polymorphic interface?
Anything that yields data in chunks will not really be affected by runtime polymorphism much.
It's only a problem when it's done per datum.