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

791–800 of 932 posts

Re: “Clean” code, horrible performance

#791

Post by _dain_ »

ysavir wrote: post #188

As a general rule, optimize for your bottlenecks . If you have a large sum of I/O and can see the latency tracked and which parts of the code are problematic, optimize those parts for execution speed. If you have frequent code changes with an evolving product, and I/O that doesn't raise concerns, then optimize for code cleanliness. Never reach for a solution before you understand the problem. Once you understand the…

It's a shifting target though.

Let's take your example of a program with a lot of I/O. A straightforward way to optimize that is to find a way to reduce the number of I/O operations you do.

And once you do that, the bottleneck shifts. You're spending less time in I/O, both in an absolute sense and relative sense. So you might run into a new non-I/O new bottleneck that was just drowned out in the noise before. So you optimize that ...

And sometimes this goes on for many iteration cycles and you end up with a 100-1000x performance improvement.

Re: “Clean” code, horrible performance

#793

Post by tomxor »

The no.1 piece of advice I give to junior programmers now, or any programmer trying to improve, is to care about your code, everything else can naturally and more safely emerge from that one principle.

The problem with laying down a bunch of arbitrary rules is that they never apply to all scenarios. As the person coming up with the rules you can easily re-evaluate where and when they don't work, but the novice receiving those rules wont necessarily have an intuition for the reasoning behind them yet, and so wont so considerately apply them. For everyone else, they need to understand that there is no silver bullet, no 10 commandments that will give them the best result, life is messy, and they need to think, develop their own intuitions by interrogating their own code in each new context - but it all starts with caring about your code, not being satisfied with a pile of spaghetti, or a pile of OOP just because OOP, or a pile of strictly pure functions just because FP. Every single rule or programming pattern is wrong given enough contexts, it's all subjective.

Discussing patterns and rules is useful, but only if they are only used as a mental anchor to think about them, not some kind of axioms of programming correctness.

Re: “Clean” code, horrible performance

#794

Post by CorrectHorseBat »

raspberry1337 wrote: post #760
rando14775 wrote: post #739

Earlier quoted context omitted.

[flagged]

>Cars weren't as big a priority for the communists. They were right too, cars and car infrastructure are super inefficient. How to say that you're a city kid, without saying you are a city kid.

Well yes, rural infrastructure is super inefficient compared to urban infrastructure.

Re: “Clean” code, horrible performance

#795

Post by flumpcakes »

WA wrote: post #643
noobermin wrote: post #641

This comment section just shows how so many developers are victims of group think. Here is actual evidence that at least hints that the primary paradigm is wrong, and immediately a bunch of nerds jump and attack, instead of taking the criticism in good faith. Compare this to discussions about FP, new languages like Rust, and so forth. This really demonstrates the primary vogue mindset is increasing complexity and hie…

What are you talking about? The first comment is literally a real sincere rebuttal: "performance doesn’t matter in 99.9% of apps".

> performance doesn’t matter in 99.9% of apps

I don't think this is a sincere rebuttal at all.

In fact, it perversely proves the point. If 99.9% of apps aren't caring about performance - that's probably why my $2000 computer is slow to open a text file.

I want all of my applications to be well performant. Using the modern web is an atrocious experience most of the time. It's strange when I stumble upon a mostly-unchanged "web 2.0" era site. It loads instantly, like, shockingly fast. It doesn't have all the SPA widgets and "interactivity" but it works, loads extremely fast, and doesn't turn my computer's fans on.

My computer is several orders of magnitude faster than my computer from 2001. Yet the applications I want to use feel slower.

People say that programmer productivity is more important than efficiency, I don't think programmers are more productive. We've just lowered the bar.

Re: “Clean” code, horrible performance

#796

Post by fartsucker69 »

rrobukef wrote: post #352
the-smug-one wrote: post #295

Earlier quoted context omitted.

I don't see how the code snippets presented are less maintainable.

I do. Because I was asked to add a convex polygon and calculate its area. And now the shape_union must be rewritten from scratch. ... And maybe we want set-operations in the future...

that's a separate thing from polymorphism vs. switch case in the post that people confuse.

if he simply kept the original "unoptimized" switch case method, what you say wouldn't apply. it couldn't. from a pure feature standpoint, a switch case is functionally identical to polymorphism except that you can't add types that are unknown at compile time (like loaded at runtime as an extension from a library or something). and that version is already faster.

what the blog post does after that point is merely point out that by having everything in one place, you see opportunities to optimize. this is a separate thing where you still have to consider whether that actually makes sense.

like, if you can guesstimate that an entirely different type is likely to enter the picture at some point, you may skip this optimization. if production realities mean that code needs to be faster, you can still apply it and add some comments about how to change it back, or just keep the original version commented out with a reference for why its there. and so on.

Re: “Clean” code, horrible performance

#797

Post by sidlls »

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…

There are a lot of people who advocate "clean code" principles without ever having read or knowing about Uncle Bob, because those "enterprise java dev like 10 years ago" folks sort of seeped into the industry.

It's the same thing with TDD zealots. Or any other fad driven development paradigm, which our industry is filled with.

Re: “Clean” code, horrible performance

#798

Post by saagarjha »

whstl wrote: post #685
saagarjha wrote: post #374

Earlier quoted context omitted.

The problem is that Casey has a very particular definition of simple which is problematic to apply in many cases.

Does he? If anything, it is the definition of "Clean Code" that is somewhat special compared to previous usage of OOP and other paradigms. Casey's definition of simple actually reminds me of the cliché by Rich Hickley. It's simple, but it's not necessarily easy.

I don’t recommend adopting “Clean Code” either for similar reasons.

Re: “Clean” code, horrible performance

#799

Post by _dain_ »

cranium wrote: post #667

You can optimize even further by creating a custom chip to compute the area of shapes in the order of billions per second. But what's the point? Where is the value? Can't say it better than Knuth: 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%. Clean code has never been about performa…

A 20x performance improvement is not a "small" efficiency.

Re: “Clean” code, horrible performance

#800

Post by fartsucker69 »

oleg_antonyan wrote: post #640
GrumpySloth wrote: post #364

This thread is, predictably, another demonstration of conflating optimisation with being aware of performance. The presented transformation of code away from “clean” code had nothing to do with optimisation. In fact, it made the code more readable IMO. Then it demonstrated that most of those “clean” code commandments are detrimental to performance. So obviously when people saw the word “performance”, they immediately…

Despite being based on science, software development is full of bs, opinions and lacks measurable metrics. How "clean" this code is? In numbers between 0 and 1 for example. What's the metric there? Does using polymorphism automatically make your code clean? We cannot reliably reason about even single responsibility b/c there's no real measure how to count responsibilities of a function. In such la-la-land some desper…

Who told you software dev is based on science? It's clearly based on toilet plumbing.
Post reply on HN