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

71–80 of 932 posts

Re: “Clean” code, horrible performance

#71

Post by pkolaczk »

davnicwil wrote: post #61

I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).

> developer time is a significantly more expensive resource than compute

Depends on the number of invocations of the program.

Re: “Clean” code, horrible performance

#72

Post by mariusor »

fer wrote: post #6

Unrelated to the content itself, am I the only one wondering if he has his t-shirt mirrored or if he's really skilled at writing right-to-left? Content wise: his examples show such increases because they're extremely tight and CPU-bound loops. Not exactly surprising. While there will be gains in in larger/more complex software by throwing away some maintainability practices (I don't like the term "clean code"), they…

He created the t-shirts specially for StarCode Galaxy[1] which is a longer form class for C++ programming in the same veign as the current video, but with a much wider scope. (As far as I know SCG is not released yet).

As a small, amusing, s(n)ide note, Casey's rants about the slowness of the Windows terminal[2] that ended up in Microsoft releasing an improved version[3], were based him wanting to implement a TUI game as an exercise in SCG and the terminal being too slow.

[1] https://starcodegalaxy.com/ [2] https://news.ycombinator.com/item?id=31284419 [3] https://news.ycombinator.com/item?id=31372606

Re: “Clean” code, horrible performance

#74

Post by thom »

There is no doubting Casey's chops when he talks about performance, but as someone who has spent many hours watching (and enjoying!) his videos, as he stares puzzled at compiler errors, scrolls up and down endlessly at code he no longer remembers writing, and then - when it finally does compile - immediately has to dig into the debugger to work out something else that's gone wrong, I suspect the real answer to programmer happiness is somewhere in the middle.

Re: “Clean” code, horrible performance

#75

Post by zaphodias »

davnicwil wrote: post #61

I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).

Yeah you're right, nobody ever said to me "use interfaces because the code it's faster".

On the other hand, when I studied dynamic dispatch and stuff like that, I don't think enough people told me "when you do that, you are making this tradeoff".

I feel like it's worth sharing this kind of knowledge in order to make better informed decisions (possibly based on numbers). There's no need to become an extremist in either direction.

Re: “Clean” code, horrible performance

#76

Post by pkolaczk »

Ygg2 wrote: post #64
abyesilyurt wrote: post #58

Earlier quoted context omitted.

My key learning is the importance of balancing performance and code cleanliness instead of blindly adhering to clean code principles.

If you optimize for readability performance would suffer. If you optimize for performance readability will suffer. Casey prizes performance over everything else.

In this particular case I find the code optimized for speed (the one using switch) to be also more readable and simpler than the code using virtual dispatch.

The problem with virtual calls in a big project is that there is no good way of knowing what is the target of the call, without some additional tooling like IDE. But in case of a switch/if, it is pretty obvious what the cases are.

Re: “Clean” code, horrible performance

#77

Post by MonkeyClub »

pkolaczk wrote: post #71
davnicwil wrote: post #61

I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).

> developer time is a significantly more expensive resource than compute Depends on the number of invocations of the program.

Not just that.

The “developer time is valuable” mantra is thrown left and right, disregarding how much of that valuable resource will be wasted down the line due to bad implementations.

If we optimize for developer time, let’s optimize across the software’s entire lifecycle, not just that first push of a MVP to production.

Re: “Clean” code, horrible performance

#78

Post by davnicwil »

TeMPOraL wrote: post #70
goodlinks wrote: post #66

Earlier quoted context omitted.

Externalised cost on the environment will hopefully one day be addressed.

Not to mention the users. For all the bullshit the marketing departments of every company spew about valuing their customers, software companies don't really give a damn about the many person-hours of users' lives they waste to save a person-minute of dev time.

Everything is a balance though, and the tradeoff may not be linear. Where they've landed on it may be the only way to get the software to customers at all in a cost effective manner.

Re: “Clean” code, horrible performance

#79

Post by oleg_antonyan »

theknarf wrote: post #55

This seems more like an argument against the object oriented model of C++ than anything else. Would have been more interesting if the performance was compared to languages like Rust.

Indeed. If anything this demo shows how badly C++ polymorphism performs. It doesn't necessarly means that all OOP languages created equal. Although I have no data to prove anything, and frankly don't care b/c all these arguments about clean vs dirty code are meaningless in an absence of formally defined rules and metrics universally enforced by some authority that can revoke your sw dev license or something like that

Re: “Clean” code, horrible performance

#80

Post by ruicaridade »

datadeft wrote: post #62

TL;DR: "Game developer optimizes code for execution as opposed to readability that 'clean-code' people suggest". There are few considerations: - most code is not CPU bound so his claims that you are eroding progress because you are not optimizing for CPU efficiency is baseless - writing readable code is more important than writing super optimal code (few exceptions: gaming is one) - using enums vs OOP is not changing…

I'm tired of every tool I install on my latest gen Intel CPU + 32GB RAM + NVMe drive machine being a complete slog.

To each their own, but I don't find Casey's performant version less readable, I don't see the need for so many abstractions.

Post reply on HN