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

671–680 of 932 posts

Re: “Clean” code, horrible performance

#671

Post by DeathArrow »

fvdessen wrote: post #546
badsectoracula wrote: post #371

Earlier quoted context omitted.

If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The…

Think of using slow patterns as using a slow programming language. After you've optimised your python program and eliminated all hotspots, the python profiler isn't going to say 'hey, this could be still 10x faster if rewritten in go'. Note that if you write a graphics engine, you aren't going to use python or even go, but something more like c, c++, rust, even though your code would be cleaner in python. Clean code…

>Clean code techniques elevate your level of abstraction and prevent some problems

What problems do they prevent?

Re: “Clean” code, horrible performance

#672

Post by Olreich »

mmarq wrote: post #194
MikeCampo wrote: post #158

Earlier quoted context omitted.

Just because you haven't been exposed this issue doesn't mean it doesn't exist. "the real situation", "no one", "in real projects", "never pop up"...give me a break lol.

His classes are doing a single multiplication, of course dynamic dispatch would have a significant cost in this scenario.

Never look at the dispatch of a big company’s Java code base then. It’s dynamic dispatch 400 layers deep for a single network call or file op or small amount of math. Sure those are more expensive operations, but the dynamic dispatch has continually out scaled the problem.

Re: “Clean” code, horrible performance

#673

Post by jzm2k »

yCombLinks wrote: post #473
scotty79 wrote: post #264

Earlier quoted context omitted.

I heard it as make it work make it work correctly make it work fast Pretty was never in the picture. But if anyone wants to add it, it should come last.

Correctly is covered by make it work

I don't think it is. There are times in projects where you're exploring the problem space and figuring out how to get implement whatever you're doing and to speed up that process, you can take shortcuts such as assuming that a value always exists, there are X many users, or this function will never fail so you `expect()` on it. Also very little testing and no documentation. Once you have something that works, it's time to make it correct by removing those assumptions and adding tests and documentation. I believe this is what the distinction between "make it work" and "make it right" is.

Re: “Clean” code, horrible performance

#674

Post by joshka »

Tomis02 wrote: post #590
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 co…

There's a good Bjarne Stroustrup quote (mentioned in Clean Code) that is more useful here (as well as a bunch more on optimization / efficiency that are worth reading):

"I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well" [1]

[1]: https://www.stroustrup.com/quotes.html

Re: “Clean” code, horrible performance

#675

Post by thermin »

rkuska wrote: post #650
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…

And let's not forget that majority of CPU cycles is spent on encoding/decoding json requests.

Still unvectorized in Java

Re: “Clean” code, horrible performance

#676

Post by coldtea »

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.

I hear this a lot, but that 0.1% when I'm actually waiting to do its calculation, it better be fast.

And the rest 99.9% of time, it better not eat my battery and memory...

Re: “Clean” code, horrible performance

#677

Post by DeathArrow »

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…

While I agree with Casey, for some situations it's hard to do. You can't really develop web app in C# and Java in a simple way. Not only you have to fight the language design, but all framework and libraries are written with OOP, clean code and design patterns in mind.

So you might write your code in a straight way, careful to not lose efficiency and then you are going to call slow code.

So his advices are easier to follow on some scenarios than others.

Re: “Clean” code, horrible performance

#678

Post by mtrower »

simplotek wrote: post #628
xtian wrote: post #528

Earlier quoted context omitted.

So why do 99% of real world applications run like garbage? What’s the culprit?

> So why do 99% of real world applications run like garbage? If you're really interested in the impact of performance issues on everyday life, you need to provide concrete examples instead of putting up unverifiable strawmen. The truth of the matter is that 99% of real world applications run just fine, and it doesn't pay off to invest in shaving milliseconds here or there. Would it be desirable to have a magic wand t…

You know, I started on some concrete examples for you, but I had to stop and back up. Really? You can't think of any examples yourself? The modern web is absolute hell to use if you aren't on modern hardware. Try it sometime; use a 10 year old phone, or an old computer that wasn't built top-of-the-line.

There's so much hardware out there that can run native applications just fine, that can play back HD video, that can run complex 3D real time video games, but crawl like molasses when loading your average webpage. Facebook and YouTube are terrible offenders, but so are your average blogs. Many banking websites are terrible (yet they don't have to be; my local credit union has a zippy website that looks attractive to boot, has modern design elements, etc.).

Maybe the hardware you're running is eye-wateringly fast, or maybe it's just barely fast enough and you don't need the cycles for anything else. But we're not talking milliseconds. We're talking order(s) of magnitude. I can't bring myself to believe you don't see at least some of it, if you just open your eyes and look around.

Re: “Clean” code, horrible performance

#679

Post by Dave3of5 »

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…

> Slow DB queries

What I've seen is slow queries but a bigger problem is actually too many queries. It's easy to do especially when using an ORM.

It mostly happens on change when you want to add something to an existing query the changer just add their new query and slop it into a loop, boom performance is gone.

Re: “Clean” code, horrible performance

#680

Post by fartsucker69 »

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…

There is nothing more maintainable about the clean code variant either.
Post reply on HN