“Clean” code, horrible performance • Hacker News Board

Re: “Clean” code, horrible performance

#321

Post by DaiPlusPlus » Tue, Feb 28, 2023, 10:35 PM UTC

dvaletin wrote: post #44

vrnvu wrote: post #11

The problem with the contemporary "clean code" concept is that the narrative that performance and efficiency don't matter has been pushed down the throat of all programmers. Re-usability, OOP concepts or pure functional style, design patterns, TDD or XP methodologies are the only things that matter... And if you use them you will write "clean code". Even worse, the more concepts and abstractions you apply to your cod…

> Even worse, the more concepts and abstractions you apply to your code the better programmer you are! I had an Android programmer, who was eager to write clean code following GOF patterns, OP and the rest of the fancy things senior developers usually do. Ended up Android team with 3 devs required 3x time to develop same feature compared to single iOS engineer.

It's often said that Design Patterns are workarounds for limitations in the expressiveness in a language: for example, the Singleton pattern is only useful in languages where you can't pass a reference to an interface implemented entirely by static methods - or the Visitor Pattern is the workaround for a language not supporting Double-Dispatch - method call chaining is a workaround for not having a pipe operator, and so on.

You said you're targeting Android, that implies you were using Java, which has its reputation for both a rigidly inflexible language-design team and its ecosystem having more design-patterns than a set of fabrics swatches - that's not a coincidence.

But for iOS, they'd be using Swift, right? Swift's designers clearly decided they didn't want to be like Java: take the best bits of C# and other well-designed languages and don't be afraid to iterate on the design, even if it means introducing breaking-changes - but the result is a highly-expressive language that, as you've demonstrated, allows just 1 Swift person to do the equivalent of 3 Java people. Swift is an actual pleasure to use, but using Java today makes me weary.

(To be clear: Java was a fantastic language when it was introduced, but it simply hasn't kept-up with the times to its own detriment, it feels like its falling behind more-and-more at time goes on - but that's going to be the fate of every programming language eventually, imo).

Re: “Clean” code, horrible performance

#322

Post by jiggawatts » Tue, Feb 28, 2023, 10:35 PM UTC

p1necone wrote: post #293

yashap wrote: post #263

Earlier quoted context omitted.

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

Casey Muratori knows a lot about optimizing performance in game engines. He then assumes that all other software must be slow because of the exact same problems. I think the core problem here is that he assumes that everything is inside a tight loop, because in a game engine that's rendering 60+ times a second (and probably running physics etc at a higher rate than that) that's almost always true. Also the fact that…

Casey makes the point that you don't have to hand-tune assembly code, but instead just write the simpler code. It's easier to write, easier to read, and runs faster too!

If there's something wrong with that advice, I can't imagine what it is...

Re: “Clean” code, horrible performance

#323

Post by 0xbadcafebee » Tue, Feb 28, 2023, 10:37 PM UTC

"Clean" is a poor descriptor for source code.

The word "clean" in reference to software is simply an indicator of "goodness" or "a pleasant aesthetic", as opposed to the opposite word "dirty", which we associate with undesireable features or poor health (that being another misnomer, that dirty things are unhealthy, or that clean things are healthy; neither are strictly true). "Clean" is not being used to describe a specific quality; instead it's merely "a feeling".

Rather than call code "clean" or "dirty", we should use a more specific and measurable descriptor that can actually be met, like "quality", "best practice", "code as documentation", "high abstraction", "low complexity", etc. You can tell when something meets that criteria. But what counts as "clean" to one person may not to another, and it doesn't actually mean the end result will be better.

"Clean" has already been abandoned when talking about other things, like STDs. "Clean" vs "Dirty" in that context implies a moral judgement on people who have STDs or don't, when in fact having an STD is often not a choice at all. By using more specific terms like "positive", or simply describing what specific STDs one has, the abstract moral judgement and unhelpful "feeling" is removed, and replaced with objective facts.

Re: “Clean” code, horrible performance

#324

Post by TeMPOraL » Tue, Feb 28, 2023, 10:40 PM UTC

jimbob45 wrote: post #291

yashap wrote: post #263

Earlier quoted context omitted.

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

Well said. The aphorism "Premature optimization is the root of all evil" is meant to mean "Build it right first, then optimize only what needs to be optimized". There's really no need to start cooking spaghetti right off the bat. Clean code with some performance tweaks will be more maintainable in the long run without sacrificing performance.

Casey's implied point is that clean code is already sacrificing performance from the start. And of course real life tells us that those "performance tweaks" will never happen.

There is this popular wisdom that security must be designed for from the start, and cannot be just added after the fact. Performance is like that too, except worse, because you actually can add security after the fact - worst-case, you treat the entire system as untrustworthy and wrap a layer of security around it. You can't do that with performance - there is no way to sandbox your app so it goes faster. You can only profile things then rip out the slow parts and replace them with fast ones - how easy that is depends on the architecture and approach you adopt early in the project.

Re: “Clean” code, horrible performance

#325

Post by hinkley » Tue, Feb 28, 2023, 10:40 PM UTC

nonethewiser wrote: post #227

hinkley wrote: post #174

Earlier quoted context omitted.

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…

Why were you making incremental changes?

"Make the change easy, then make the easy change" hadn't even been coined as a phrase yet when I discovered the utility of that behavior. When I read 'Refactoring (Fowler)' it was more like psychotherapy than a roadmap to better software. "So that's why I am like this."

When we get unstuck on a problem it's usually due to finding a new perspective. Sometimes those come as epiphanies, but while miracles do happen, planning on them leads to disappointment. Sometimes you just have to do the work. Finding new perspectives 'the hard way' involves looking at the problem from different angles, and if explaining it to someone else doesn't work, then often enough just organizing a block of code will help you stumble on that new perspective. And if that also fails, at least the code is in better shape now.

Not long after I figured out how to articulate that, my writer friend figured out the same thing about creative writing, so I took it as a sign I was on the right track.

I do know that the first time I was doing that, it was for performance reasons. I was on a project that was so slow you could see the pixels painting. My first month on that project I was doing optimizations by saying "1 Mississippi" out loud. The second month I used a timer app. I was three months in before I even needed to print(end - start).

Re: “Clean” code, horrible performance

#326

Post by jiggawatts » Tue, Feb 28, 2023, 10:42 PM UTC

stunpix wrote: post #150

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere "? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method…

> The real situation: a virtual method is called only a few hundred times and is barely visible in profiling tools.

The reality is that the entire Java ecosystem revolves around call stacks hundreds of calls deep where most (if not all) of those are virtual calls through an interface.

Even in web server scenarios where the user might be "5 milliseconds away", I've seen these overheads add up to the point where it is noticeable.

ASP.NET Core for example has been optimised recently to go the opposite route of not using complex nested call paths in the core of the system and has seen dramatic speedups.

For crying out loud, I've seen Java web servers requiring 100% CPU time across 16 cores for half an hour to start up! HALF AN HOUR!

Re: “Clean” code, horrible performance

#327

Post by [deleted] » Tue, Feb 28, 2023, 10:42 PM UTC

onion2k wrote: post #247

mquander wrote: post #196

Earlier quoted context omitted.

> 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. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because o…

For what it's worth, less than 4% of websites use React (approximately 4% use any JS framework) . If you believe the web is slow because of React you are wrong. It's not even due to JS.

[deleted]

Re: “Clean” code, horrible performance

#328

Post by overgard » Tue, Feb 28, 2023, 10:42 PM UTC

mabbo wrote: post #179

I 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 perfo…

I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin definition of "Clean Code"). Things like dependency injection and runtime polymorphism can make it really hard to trace exactly what happens in what sequence in the code, and things like asynchronous callbacks can make things like call stacks a nightmare (granted, you do need the latter a lot). Small functions can make code hard to understand because you need to jump to a lot of places and lose the thread on the sequential state (bonus points if the small functions are only ever used once by one other function). The more I work in code bases the more I find that overusing these "clean" ideas can obscure the code more than if it was just written plainly. I think a lot of times, if a technique confuses compiler optimization and static code analysis, it's probably going to confuse humans also.

Re: “Clean” code, horrible performance

#329

Post by replygirl » Tue, Feb 28, 2023, 10:43 PM UTC

datavirtue wrote: post #289

gary_0 wrote: post #277

Earlier quoted context omitted.

I just loaded cnn.com while looking at the CPU utilization graph: 50% use of my 8 logical cores at 4.5GHz for the better part of a second. So no, it's not just network latency. Doing multiple parallel network requests, parsing, doing layout and applying styles, running scripts, decoding media... a modern website and browser devours CPU time.

So those who visit Fox and CNN are helping to destroy the planet. Or is it the developers fault? Can't be the developers.

one of them must be to blame! readers and publishing engineers famously sit atop corporate decision-making hierarchies, and no one else in a mass media enterprise ever did anything wrong, certainly not before the web was a thing

Re: “Clean” code, horrible performance

#330

Post by josephg » Tue, Feb 28, 2023, 10:45 PM UTC

rwalle wrote: post #292

gdprrrr wrote: post #251

Earlier quoted context omitted.

Have you measured CPU time? A very large factor will be Disk IO and Network

Exactly. The webpage is probably asking for resource from 10 different servers and one of them is a bit slower than the others, and the page rendering itself likely doesn't take very long.

No; I have no idea why its so slow. Its kind of hard to tell - I guess I could use wireshark to trace the packets. But who cares? At least one of these things is true:

- It makes horribly inefficient use of my CPU

- It needs an obscene number of network round-trips to load

- One of the network servers that discord needs to open takes seconds to respond to requests

This isn't a new problem. Discord always takes about 10 seconds to open on my computer. (Am I just on too many servers?)

It should open instantly. Everything on modern computers should happen basically instantly. The only reason most software runs slowly is because the developers involved don't care enough to make it run fast.

Except for a few exceptions like AI, scientific computing, 3d modelling and video editing, modern computers are fast enough for everything we want to do with them. Software seems to have higher requirements each year simply because the developers get faster computers each year and spend less effort keeping their software tight and lean.