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

“Clean” code, horrible performance

computerenhance.com

Post reply on HN
Print view View original

581–590 of 932 posts

Re: “Clean” code, horrible performance

#581

Post by sicp-enjoyer »

davnicwil wrote: post #61

I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).

> developer time is a significantly more expensive resource than compute

This also presupposes that making a fast program is a lot more work. However poor performance is usually due to negligence rather than a lack of optimization effort. All you need to write reasonably fast code by default (without micro-optimizing) is:

1. a good knowledge of available algorithms 2. a good understanding of the problem

1. Is a one-time investment on the programmers part that benefits all future programs they write. There is no marginal cost to being familiar with what's available in . 2. Has a marginal cost, but it's probably a time saver anyway. Measure once, cut twice.

Re: “Clean” code, horrible performance

#582

Post by randomdata »

hinkley wrote: post #366
randomdata wrote: post #350

Earlier quoted context omitted.

> TDD is about writing new code. TDD is about documenting behaviour. Which is why it was later given the name Behaviour Driven Development (BDD), to dispel the myths that it is about testing. It is true that you need to document behaviour before writing code, else how would you know what to write? Even outside of TDD you need to document the behaviour some way before you can know what needs to be written. A function'…

> A function's behaviour should have no reason to change after its behaviour is documented. That's only true with spherical cows. That something happens is a requirement. When it happens is often only as specific as 'before' or 'after' but tests often dictate that they happen 'between', which is not an actual requirement, it's an accident of implementation. It was 'easy' to put it here. Nowhere is it written that beh…

> Nowhere is it written that behavior in a system is strictly additive.

For a unit of the same identity to suddenly start doing something different is plain nonsensical, never mind the technical challenges that come with breaking behaviour that should scare anyone away from trying. Logically, a unit is additive until the unit are no longer used, at which point it can be eliminated.

> But the old tests disappear with the old code (when the feature toggle goes away).

Absolutely, but static analysis can easily determine that the tests being removed correspond with units being removed. If (TDD) tests are removed and the unit code isn't, something has gone wrong and your infrastructure should make this known.

Re: “Clean” code, horrible performance

#583

Post by pugz »

gary_0 wrote: post #277
PragmaticPulp wrote: post #216

Earlier quoted context omitted.

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time Unless we’re talking about specific compute-intensive websites, this is almost certainly network loading latency. Modern web browsers are very fast. Moderns CPUs are very fast. Common, random websites aren’t churning through “multiple seconds” of CPU time just to render.

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.

I was about to dispute what you said, but I realised I was running uBlock origin. What machine and browser are you using? I just used Chrome (on MacOS using an M1 Pro CPU) to run a performance profile and loading cnn.com took the following:

- Loading: 29ms with uBlock vs 42ms without

- Scripting: 548ms vs 1850ms (!!)

- Rendering: 42ms vs 105ms

- Painting: 8ms vs 29ms

- System: 216ms vs 295ms

- Idle: 460ms vs 8707ms

Holy shit, advertising and trackers are absolute resource hogs.

Re: “Clean” code, horrible performance

#584

Post by randomdata »

larsonnn wrote: post #500
randomdata wrote: post #229

Earlier quoted context omitted.

> I think the author is taking general advice Not just general advice, but advice that is meant to be applied to TDD specifically. The principals of clean code are meant to help with certain challenges that arise out of TDD. It is often going to seem strange and out of place if you have rejected TDD. Remember, clean code comes from Robert C. Martin, who is a member of the XP/Agile gang. The author cherry-picking one…

But is this trade off not a little bit to much? It reminds me of Twitter or other companies which starting to change programming languages for performance reasons.

Is testable code a tradeoff too much? That cannot be answered globally, only locally. That's why we have engineers, after all. You could eliminate the entire profession of engineering if "which tradeoff is best" could be answered broadly without deep understanding of specific circumstances.

Re: “Clean” code, horrible performance

#585

Post by Ygg2 »

andyferris wrote: post #389
Aeolun wrote: post #351

Earlier quoted context omitted.

> If there's something wrong with that advice, I can't imagine what it is... It will start getting really annoying when you try to add shape ‘hexagon’ and need to figure out all the places where a shape can potentially be used, just so you can update the switch statements.

Many languages provide unions or sum types along with exhaustiveness checking to make this very easy (frequently not OO-inheretence based languages though).

What happens if library user wants to extend functionality? They can't inject their code into the library.

Re: “Clean” code, horrible performance

#586

Post by gumby »

CyberDildonics wrote: post #245
gumby wrote: post #171

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.

Cost of execution to who? If you don't care about the speed of your program when I execute it, we end up with electron based VPN GUIs that have menus that run at a few frames per second or electron based disk formatters that are a 400 MB download to ultimately run a command line process. If you don't care about execution speed, I don't want to use it.

The large number of electron apps demonstrates that most companies don’t really care about the customer.

But even on the back end, companies seem willing to scale cloud costs rather than make the lumpy and “risky” investment in hiring.

I don’t agree with it but I see it everywhere.

Re: “Clean” code, horrible performance

#587

Post by Ygg2 »

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…

Reminds me of a joke where programmer optimized most frequently used method in imgur clone from 1s to 0.01s, because customer complained UI was slow to respond.

Congratulations. Taps on the back, champagne all around. Customers call. Same complaint.

Programmer asks "Well, did something change at least?". "Loading bar now flickers more", answers customer.

Re: “Clean” code, horrible performance

#588

Post by ummonk »

Just in terms of readability and maintainability I find polymorphism to be significantly worse than switch-statements. It's hard to locate all the implementations of a particular function and read through them and edit them when they aren't in one place in a single switch statement. Higher performance is merely extra icing on the cake when using switch statements over polymorphism.

Re: “Clean” code, horrible performance

#589

Post by ummonk »

nerdponx wrote: post #451
teki_one wrote: post #318

Earlier quoted context omitted.

The thing that sets him off is that he is using a computer with enormous computing power and everything is slow. He does have a narrow view, but it does not make his claims invalid. I liked that his POC terminal made in anger made the Windows Terminal faster. But even in that context it was clear that by making some tradeoffs - which the Windows Terminal team can not make (99.99% of users do not run into the issue, b…

But how much of that slowness is due to code that values "cleanliness" excessively? I bet that if you look at the source of nearly any application on your PC, it will be very much not clean on average.

I think it would certainly value the kind of "clean" design patterns (or anti-patterns as I consider most of them) that object-oriented programming evangelists espouse.

Re: “Clean” code, horrible performance

#590

Post by Tomis02 »

rudolph9 wrote: post #335

> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3% https://dl.acm.org/doi/10.1145/356635.356640 The author of the post fails to articulate how we strike a healthy balance and instead comes up with contrived examples to prove points that only really apply to contrived examples.

You managed to misunderstand both Casey Muratori and Donald Knuth. You are not alone, the majority of the industry seems to have gotten it wrong.

Casey tells you that following "Clean Code" can give you a huge performance hit for no obvious benefit. And even if "Clean Code" were to be more maintainable (it's not; in my experience, it's actually worse for maintainability), you should still be extremely aware of the cost you're likely to pay down the track. It's not a contrived example, it's literally textbook "Clean Code". I'll say it again: "Clean Code" gives you slower, less maintainable code, and you get nothing from it. Maybe you can afford it, maybe in your use case it's not a big deal, but you should be informed.

Knuth tells you to measure before optimizing, which Casey did. Knuth does NOT tell you "don't worry about performance, you'll optimize later". You quoted Knuth but stopped right before the best part:

> A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; BUT ONLY AFTER THAT CODE HAS BEEN IDENTIFIED [emphasis mine]. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

To recap: "A good programmer will not be lulled into complacency by such reasoning" - in other words, just because 97% of the code may not need optimization does NOT mean you should not be thinking about performance.

Knuth's point is that when identifying hotspots, programmers were relying on intuition rather than measurement. That's what he meant by "premature optimization". Knuth did not mean (especially since it was the 70s) you should write "Clean Code" that you know has worse performance for little benefit.

And Knuth does not write "Clean Code", by the way.

> The author of the post fails to articulate how we strike a healthy balance

There is no healthy balance between a good idea and a bad idea. Just eliminate the bad idea.

Post reply on HN