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

381–390 of 932 posts

Re: “Clean” code, horrible performance

#381

Post by saagarjha »

TeMPOraL wrote: post #324
jimbob45 wrote: post #291

Earlier quoted context omitted.

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

Adding performance to software after the fact is typically far easier than securing it. Layers of security have to be watertight, and generally they are not if you don't design them from the start to be. A good performance engineer works in the constraints of their project to balance minimal code changes with performance wins.

Re: “Clean” code, horrible performance

#382

Post by TeMPOraL »

ilyt wrote: post #284
Kukumber wrote: post #214

Earlier quoted context omitted.

0 responsibility developers you have Japan infrastructure, and you have Turkey infrastructure 6.1 quake in Japan = nothing destroyed 6.1 quake in Turkey = everything collapses The engineers in Turkey probably didn't value performance and efficiency It's the same for developers, you choose your camp wisely, otherwise people will complain at you if they can no longer bear your choice You act like innocent, but your cod…

> The engineers in Turkey probably didn't value performance and efficiency Uh, no. It was corruption. They were standards, that worked, but people didn't do it, plain and simple.

Yeah, it's a bad and unnecessarily inflammatory (and arguably disrespectful) example. But the rest of the points GP makes are spot on.

A "blame systems over individuals" version would be that the industry is externalizing bad performance onto users, damaging environment, causing frustration, wasting lives, and occasionally even actually killing people (shitty ER/hospital software comes to mind) - because there's no good feedback mechanism to force software companies to internalize those costs.

Re: “Clean” code, horrible performance

#383

Post by Veliladon »

fvdessen wrote: post #272
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 once optimised a SPA app that had to be really fast for usability reasons (industrial use), I replaced all the 'high level' JS patterns such as map, filter, and frontend framework things to use just if else and for loops and native dom manipulation, and it ended up more than 10x faster, each click would update the app in one frame, it was very noticeable. So yes CPU cycles do matter for websites, even with modern h…

Yep. In Rust land for instance it'd get compiled down to a for loop and be ridiculously fast. Every time you do a .map or a .filter in JS though it gets abstracted down to a function that makes an allocation for the ENTIRE ARRAY and then copies the entire array into that new array doing whatever you asked to data. The JS VM might be able to optimize some of it away but the abstraction is awful.

So if you were to manually run a for loop over an array instead of iterating through it I'm not surprised you got an order of magnitude faster performance.

Re: “Clean” code, horrible performance

#384

Post by int_19h »

adamrezich wrote: post #316
TheBigSalad wrote: post #198

Earlier quoted context omitted.

Still... this isn't the reason games are slow.

I'm not sure why you would say that—it's certainly a reason why some (not AAA) games are slow.

It should be noted that there were AAA games written in this fashion, and they were not slow. All method dispatch was virtual in UnrealScript, for example.

Re: “Clean” code, horrible performance

#385

Post by julik »

heisenbit wrote: post #281
simplotek wrote: post #250

Earlier quoted context omitted.

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a textbook example of an hyperbolic fallacy. There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time". This blend of specious reasoning is the reason why the first rule of software o…

How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?

By someone presenting plausible evidence that not having that 1% optimised costs the organization money/business, and leadership that would listen

Re: “Clean” code, horrible performance

#386

Post by axilmar »

In C++, you can have clean code and performance, by utilizing templates.

In the example given, all polymorphism can be removed, and the shapes can be stored in std::tuple structure.

And then the operations would be faster than C, since no switch statement would be needed.

Re: “Clean” code, horrible performance

#387

Post by maerF0x0 »

If instead of measuring the benchmark of a specific optimized code against a non-optimized code we instead measure the time when the user gets their answer in many cases the non-optimized code will be several months faster. Why? Because it takes time to do optimizations and I can ship the non-optimized sooner.

Similarly we can then look at an iterated design and realize the optimized code is frequently going to be harder to refactor or understand (a precondition of refactoring). So now the time to when a customer gets their answer is delayed again.

Optimization step comes long after clean code. Clean code is most useful in the first 2 of the typical 3 steps[1]

1. Make it work (iterations of what working even means) 2. Make it right (iterations of what right even means) 3. Make it fast.

[1]:https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Re: “Clean” code, horrible performance

#388

Post by hsn915 »

yashap wrote: post #263
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…

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…

All of these are instances of doing something _wasteful_, which is the #1 issue he mentions in the list of things that cause performance degradation.

Now, your argument seems to be: in the real world, there's so much waste, that virtual function calls pale in comparison.

This does not debunk his main point, which seems to me at least the following: all things being equal, writing code with virtual functions that do a tiny amount of work and "hiding implementation details" makes performance worse, sometimes by an order of magnitude.

Now, there maybe situations where you _have_ to use virtual functions, because you are writing a library for other people to use, and you can't dictate ahead of time how they will use it.

This again does not invalidate the point. You need to be _aware_ of the performance implications of this, and mitigate it. He said the following in the comment section on the article:

> Try to make it so that you do very rare virtual function calls, behind which you do a _large_ amount of work, rather than the "clean" code way of using lots of little function calls.

Re: “Clean” code, horrible performance

#389

Post by andyferris »

Aeolun wrote: post #351
jiggawatts wrote: post #322

Earlier quoted context omitted.

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

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

Re: “Clean” code, horrible performance

#390

Post by GuB-42 »

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…

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something.

Assuming it is right, there is something called multitasking, the CPU, RAM, and most importantly, the cache is not all yours, if there is 1000 pieces of software like yours, that's 100%. You may argue that 1000 pieces of software is unreasonable, and you would mostly be right, but it happens, and mostly for the same reason software isn't optimized: quantity over quality.

Another issue is that you have to make a distinction between throughput and latency. You don't have to keep up with a sustained 100 actions per second, people don't go that fast, but you definitely have to respond within tens of milliseconds, because more than that is noticeable. Latency is much harder to optimize and if you are in the critical path, these cycles may matter.

A lot of devices are battery powered these days, and all these wasted cycle are reducing the battery life of the entire system. Mobile devices are crazy powerful these days, but this power is meant to be used sparingly. And even with line powered devices, I think we waste enough energy as it is...

And finally, what is the point of "clean code"? Hopefully not just because it gives software architects boners. The point is usually to make software that will last: easier maintenance, less bugs, etc... But performance bugs exist too, and one of the most common software evolution is to do more of what the software already does. An image editing software will process more and bigger images, a database will store more entries and more details about each entry, documents will get larger, etc... You may even find that your users are using some feature on a scale you never intended, maybe someone is pasting entire books on your note taking app, and it may turn out working quite well... if you cared about performance. Not caring about performance is technical debt, and it may negate the advantage of using "clean code" in the first place.

Post reply on HN