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

831–840 of 932 posts

Re: “Clean” code, horrible performance

#831

Post by [deleted] »

Zvez wrote: post #701
whstl wrote: post #433

Earlier quoted context omitted.

Not necessarily in the general case. If the program is a single user, locally ran program, then sure. If it's some sort of backend or distributed service, this is just wasted performance that can be used to serve more users. Virtually every distributed service built today is able to take advantage of this. With a non-pessimal design, not only you are able to pay less money on servers in the long term, you're also abl…

using 'unclean' code practice will increase development costs. And more importantly - maintainability of such code. >Virtually every distributed service built today is able to take advantage of this most of built today services can take much more advantage in using better system design practices.

[deleted]

Re: “Clean” code, horrible performance

#832

Post by knighthack »

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…

It wasn't about the tradeoffs that the Windows Terminal team "can not make" - it was about alternative optimizations and performance concerns that they arrogantly refused to consider as being possible, and which ought to have been considered if they were being properly competent.

Engineering tradeoffs are real. But hiding behind them every time when it can be pointed out that they don't actually apply - and when demonstrated with concrete evidence - is another thing altogether.

Re: “Clean” code, horrible performance

#833

Post by plorkyeran »

aforwardslash wrote: post #734
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…

> He does have a narrow view, but it does not make his claims invalid. I would tend to disagree on this, specially when claims come from the gamedev world. Games are presented as finished pieces (even when they aren't), and not just a release milestone. Ideally, a game is a one-off effort where you write a piece of code and if you're lucky, you won't have to touch it again. So, doing one-off optimizations instead of…

"Games are presented as finished pieces" is an idea that's at least a decade out of date. The industry has gone very hard on the idea of Games as a Service and it's now normal for AAA games to receive years of content updates.

Re: “Clean” code, horrible performance

#834

Post by xtian »

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…

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

You're taking deep quaffs of the Kool-Aid and so are most of the people commenting on this story. General software responsiveness and reliability (i.e., usefulness) has been in decline for decades. This is an objective fact.

Writing objective reality off as mere "milliseconds", "edge-cases", or only relevant for "toy problems" exemplifies the arrogance and severe incompetence of most programmers. People are seriously trying to talk down to Casey Muratori when in all likelihood they haven't accomplished even 1% as much as him as programmers.

I get it—no one wants to leave fantasy-land as long as the easy money is flowing. But sooner or later the glittering carriage turns back into a pumpkin.

Re: “Clean” code, horrible performance

#835

Post by overgard »

wsc981 wrote: post #509
overgard wrote: post #328

Earlier quoted context omitted.

I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin definition of "Clean Code"). Things like dependency injection and runtime polymorphism can make it really hard to trace exactly what happens in what sequence in the code, and things like asynchronous callbacks can make things like call stacks a nightmare (granted, y…

There's some videos on the internet claiming object oriented programming is pretty bad in many situations. And lately I've been wondering if there's a kernel of truth in this statement. As an alternative, often procedural programming is advised instead. I think a lot of the clean code advice in general related to object oriented programming. I've noticed that once my Lua programs (games) grow to reasonable size, it b…

Separating code from data definitely helps for serialization; while they aren't great for game development it's incredibly nice in typescript/javascript to do it that way. It can also help for things like network code or for cloning an object.

Re: “Clean” code, horrible performance

#836

Post by overgard »

guhcampos wrote: post #683

I don't like most of these "principles", as anyone can verify by looking at my previous comments, but this article is cherry-picking to its utmost level of unfairness. These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics. I've never seen anyone seriously try to write computer graphics while "keeping functions small" and "not mixing le…

Yes and no, I think that what can happen if you only focus on "performance critical code" is the rest of your code is slow and incredibly unfriendly to cache, but there's absolutely nothing you can really do about it past a point. Like, if all your code is 5x slower than it possibly could be, then even after you fix the performance critical bits you have this ugly tax everywhere else that you can't do anything about other than a rewrite. And I do think that matters, look at various projects written in a language like python where bits have been written in C, but you still have all this slow interpreted stuff. (I like Python btw, I'm just making a point that if performance matters it doesn't just matter in loops)

Re: “Clean” code, horrible performance

#837

Post by bbatha »

AnIdiotOnTheNet wrote: post #780
bbatha wrote: post #199

Earlier quoted context omitted.

Is Blow even a good example to look at? He's released 2 games in 18 years which definitely had phenomenal game play but are not technically complex even for the the time.

Yes, he is a good example. His games are as highly regarded as they are because he takes the time to really work through everything about them and ensure they're the product he wants. If you watch his streams you'll see that he is constantly experimenting with things, both gameplay-wise and in the engine... and now in his own compiler for his own programming language. Jon is not making the by-the-numbers annual entry…

Look I'm a huge fan of his games! And I really can't understate how influential his game design nor the work he does for the indie community. However, I think a lot of folks tend to assume his software engineering skills are great because his game design is excellent. I don't think that's an earned position. Releasing 2 games in 18 years that are not pushing the technical envelope does not scream software engineering expertise. You say he has more credits but only one of those is programming since Braid. On the other hand, on a software engineering level those paint by numbers Modern Warfare and FIFA games are both more technically impressive and are designed for fast iteration.

Moreover he's pushing a particular paradigm and view point that is in many ways the opposite of clean code. He pushes for still doing very low level design with minimal abstractions. But even at the time Braid could have been written in python SDL wrappers and probably had similar performance, and the witness could have used unity. If clean code is about maintenance and time to market, the Blow paradigm hasn't proven that its needed or fixes the holes in clean code. This is not to say clean code is perfect just that Blow hasn't cracked the nut either and I don't know why people act like he is the final word, or honestly even a respected voice, in game software engineering. On the other hand, if Blow wanted to talk about managing indie studios or game design my ears would prick up instantly.

Re: “Clean” code, horrible performance

#838

Post by camgunz »

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.

Conversely it's really annoying to add a new method to each shape--you've got to open them all up and add shape-specific code for them with a bunch of boilerplate. With switch statements you just add one more function.

This is the "expression problem": https://en.m.wikipedia.org/wiki/Expression_problem

Re: “Clean” code, horrible performance

#839

Post by gitgud »

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

Go to a slow website on Chrome. Open dev tools and turn on "enable paint flashing", you'll see a seizure inducing light show of re-rendering...

It's certainly a huge problem for real world applications

Re: “Clean” code, horrible performance

#840

Post by hburd »

gspencley wrote: post #789
hburd wrote: post #786

Earlier quoted context omitted.

I don’t think the percentage of time waiting for input has anything to do with this. Outside of video games, the way most people will see performance problems is in the latency of their UI interactions. You press a button and want to see the result as fast as possible. In other words, the user’s entire perception of your program’s performance falls into that 0.1%.

Performance is not an absolute. At the end of the day it is about user experience. From a computer science point of view, we can measure memory and CPU usage, but if the users haven't been complaining then what problems are you actually solving (at least from a product POV)? Performance for performance sake is an interesting and appealing challenge to us engineers. I was writing C code in the 90s and I miss being tha…

I agree with almost every one of your points. I think I oversimplified my original point for the sake of clarity.

If you are throwing out maintainable code for the sake of performance, it had better be because you know that it's your bottleneck, and that the performance increase is worthwhile in the first place. "Performance for performance sake" shouldn't exist anywhere outside of hobby projects.

I would argue that responsive user interfaces are really important to user experience. Not many people are complaining because everyone is used to unresponsive apps, but that doesn't mean users wouldn't appreciate a more responsive app.

I would also add that there isn't always a tradeoff between performance and maintainability. If you can adopt some performant coding patterns that don't sacrifice maintainability, then absolutely do that. I think Casey's example of "switch-based polymorphism" is one such pattern(and I think the fact that Rust took a similar route to polymorphism is a vote in favour of this pattern).

Post reply on HN