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

521–530 of 932 posts

Re: “Clean” code, horrible performance

#521

Post by whstl »

teki_one wrote: post #318
p1necone wrote: post #293

Earlier quoted context omitted.

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…

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 even in that context it was clear that by making some tradeoffs"

It was literally a weekend POC, and Casey Muratori even went beyond the POC part and fixed some emoji/foreign language bugs that were present in the Terminal.

Also, his intent was not to replace the Terminal. His intent was to demonstrate that it was possible to do the optimization in the way he suggested. Originally a Microsoft PM dismissed his suggestions and claimed it would be a "doctoral thesis project" or something.

All this "yeah it's a narrow view" is just moving the goalposts more and more. Not only he has to do a "doctoral thesis project" in a few days, he also has to completely replace a tool that's already written, bells and all? Where does it stop?

Re: “Clean” code, horrible performance

#522

Post by EVa5I7bHFq9mnYK »

jbverschoor wrote: post #421
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.

switch isn't 'invented' for enums. switch is a low-level construct which mimics several goto's / jumps. It's just as bad, except for the case where you have either: a) multiple behaviors for the same value, b) need to pass through (not break). b) is the nr 1 reason I hate switches, and my nr 2 reason is that most languages don't support proper enums, and will fail when you don't handle all possible values

Switch was invented because it allows to replace several ifs and gotos with a precomputed static jump table, an optimization trick.

Re: “Clean” code, horrible performance

#523

Post by naniwaduni »

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. If you're writing a AAA video game, or high performance calculation software then sure, go crazy, get those improvements.

Value of time is disproportionately weighted by user attention, which is at its highest right around when user input is happening.

Re: “Clean” code, horrible performance

#524

Post by tharkun__ »

loup-vaillant wrote: post #491
simplotek wrote: post #456

Earlier quoted context omitted.

> I realised when I implemented EdDSA for Monocypher that optimisations compound. I feel you're missing the whole point. It's immaterial whether anyone can get to optimizations that compound multiplicatively. The whole point is that halving something that costs nothing earns you nothing. That's the whole point. Go ahead and shave off that millisecond. Will anyone actually notice whether you add or remove that penalty…

People did notice. Quite a few happy users are glad signature verification took less than a second instead of more than 3. Or 30, if you compare to some of the alternatives. Others love the fact it uses 2KB of stack space instead of 5. Monocypher's speed was actually an important component in its success in the embedded market, even though I didn't explicitly target it initially (I was lucky my portability driven dec…

Not your parent but I think that is exactly the point lots of people here are making.

There definitely are niches where there are quite a few performance optimization opportunities that users do care about.

In your example making something a user is actively waiting for go from 3 seconds to less than one is a great optimization target. What is not a great optimization target is making something the user is actively waiting for and that takes 30ms take 25ms instead. That's wasted money on developer time.

If your "user" is a developer of embedded software with memory constraints and using your library leaves them more room that's awesome. If your user was someone using the library on a general purpose computing device with loads of memory then the 2 vs. 5 does nothing.

Re: “Clean” code, horrible performance

#525

Post by osigurdson »

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 think there is a relatively comfortable middle ground. High quality, readable and performant code are not mutually exclusive optimization quantities - though they will start to compete against each other in the extreme. Often, O(WTF) algorithms are complicated, full of useless fluff and hard to understand - occasionally attempting to follow Uncle Bob's unresearched and unexamined ideas.

Re: “Clean” code, horrible performance

#526

Post by samdafi »

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…

Just a quick nudge back on this: people in DSP would disagree with the assertion that nobody is going over big loops and using a virtual method on each element. We often have to process at least 88k elements per second in real time, through many many different processes. If any of those processes are defined using factories that spit out classes with polymorphic inheritance and virtual functions it certainly becomes an issue.

As a result some styles of writing code just don’t work for the audio thread at all, and we’d have to simply avoid or rewrite libraries written this way.

There are just some domains where standard practice for cleanliness is different because of your constraints.

I mean, it’s to the point we’ve got die hards in this industry who insist on putting all functions inlined in headers (not that I agree!)

Re: “Clean” code, horrible performance

#527

Post by tharkun__ »

ilyt wrote: post #254
mabbo wrote: post #234

Earlier quoted context omitted.

I don't disagree that the balance is shifting towards "why is this taking so long". There's ebbs and flows in that ecosystem. But overall, I think you overestimate how much time you spend loading the website and how much time it's just sitting there, mostly idle. And in the end, as long as it's fast enough that users don't stop using the site/webapp/program/whatever, then it's fine, imho. When it becomes too slow, th…

> But overall, I think you overestimate how much time you spend loading the website and how much time it's just sitting there, mostly idle. reading the website is productive. Waiting on it to load is not. I'd rather have app burn a whole core whole time if it cut 1s off load time when clicking something.

I think the point would be: what if instead of using a whole core and it takes 2000ms to load because it is essentially "spinning its wheels" it would only use half a core and it takes 50ms?

2s you notice as a user. 50ms you won't. In fact even 500ms you won't notice too much but we are getting close to where optimization will be noticeable to a user.

Re: “Clean” code, horrible performance

#528

Post by xtian »

engineeringwoke wrote: post #501
mquander wrote: post #370

Earlier quoted context omitted.

The subfields of programming I know the most about are game development, networking, and web development, and in all of those, it's not the case that only 1% of the code is in the "edge case" where performance matters at all. For example, in the case of web development, if you build a medium-sized website with React (i.e. pretty normal behavior nowadays), then if you make default decisions that don't consider perform…

Re-renders are incredibly cheap in the big picture. They are not a source of performance bottlenecks in 99% of real world applications

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

Re: “Clean” code, horrible performance

#529

Post by sidlls »

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…

Like everything else in the software industry the context does matter: at larger scales small gains in performance translate to large savings in costs (infrastructure, maintenance, etc.).

Also, "clean code" (as in from the "Clean Code" book) is generally not good advice for most programs anyway. Not only does it eat performance, it's not all that great for building maintainable, extensible systems.

Post reply on HN