Live data from Hacker News

“Clean” code, horrible performance

computerenhance.com

541–550 of 932 posts

Re: “Clean” code, horrible performance

#541
post #410
post #169

Earlier quoted context omitted.

Doing things without libraries (except the stuff built into Windows XP?) is the whole point of the project.

The problem is people get hooked into Casey's misanthropic philosophies and take his rants as gospel, and wind up believing Handmade Hero represents the way game development should be done, that libraries and frameworks can't be trusted, that C++ shouldn't be used at all, and you should implement as much from scratch as possible, when none of that is true.

refterm

Re: “Clean” code, horrible performance

#542
post #541
post #410

Earlier quoted context omitted.

The problem is people get hooked into Casey's misanthropic philosophies and take his rants as gospel, and wind up believing Handmade Hero represents the way game development should be done, that libraries and frameworks can't be trusted, that C++ shouldn't be used at all, and you should implement as much from scratch as possible, when none of that is true.

refterm

https://news.ycombinator.com/item?id=28745507

Re: “Clean” code, horrible performance

#543
post #92

Earlier quoted context omitted.

If you're talking about Handmade Hero, the real answer to programmer happiness is not using a language you despise and refusing to leverage the features of, not refusing to use libraries in that language or frameworks, not re-implementing everything from first principles, and to actually have your game designed first (not designing while you code.)

> and to actually have your game designed first (not designing while you code.) tell me you've never made a game without telling me you've never made a game

hahahaahahaha, that's accurate af

Re: “Clean” code, horrible performance

#544
post #277

Earlier quoted context omitted.

I just loaded cnn.com while looking at the CPU utilization graph: 50% use of my 8 logical cores at 4.5GHz for the better part of a second. So no, it's not just network latency. Doing multiple parallel network requests, parsing, doing layout and applying styles, running scripts, decoding media... a modern website and browser devours CPU time.

Jira cloud famously takes 30-60 seconds on even a fairly high-end laptop, which is just staggering. I can install an entire operating system into a virtual machine in that time.

> Jira cloud famously takes 30-60 seconds on even a fairly high-end laptop,

I use Jira every day and, no, it does not take 30-60 seconds to load a page.

The hyperbole in this comment section is something else. Either that or people are using 15 year old computers to browse the web.

Re: “Clean” code, horrible performance

#545
Lots of very correct things said there...except for this:

"The more you use the “clean” code methodology, the less a compiler is able to see what you're doing. Everything is in separate translation units, behind virtual function calls, etc. No matter how smart the compiler is, there’s very little it can do with that kind of code."

I suppose even that is true, but JIT compilation regularly walks right around those problems. Yes, your code is written to say virtual this, or override that...but the JIT don't care. Is it looking at a monomorphic call site? Or even if it's not, is it ok to think of it as monomorphic right now? Great -- inline away.

All that being said...I once got into a readability tiff over the use of a Java enum in a particularly performance sensitive chunk of code. I went with ints so I could be very, very explicit about exactly what I wanted, and the rather large performance gain...and lost. Yay!

Your mileage may vary, and your measurements may vary.

Re: “Clean” code, horrible performance

#546

Earlier quoted context omitted.

If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler will not give you any idea that it could be still 10x faster.

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 techniques elevate your level of abstraction and prevent some problems, but at the (significant) cost of performance. It's of course always a matter of trade-offs and this matters more or less depending on which problem you are trying to solve.

Re: “Clean” code, horrible performance

#547
post #533

Earlier quoted context omitted.

> CPU cycles are much cheaper than developer wages. CPU cycles are cheap. Dev time is expensive. User time is sacred . https://www.lesswrong.com/tag/scope-insensitivity

>User time is sacred. Why? What if the user is a machine operator? He is standing around waiting for the machine to finish it's current cycle. As long as he can get his data entry done in the time he is waiting it costs the business nothing.

I am not sure how to explain that "user time is sacred" is from the point of view of the user, not of the business where the user is treated as a cog in a machine.

Re: “Clean” code, horrible performance

#548
post #234

Earlier quoted context omitted.

> 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. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because o…

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…

This is a few years old, but gives a sense of how much money might be left on the table due to a slow loading web page:

https://www.marketingdive.com/news/google-53-of-mobile-users...

Re: “Clean” code, horrible performance

#549

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…

> The same thing is happening at bigger companies, at some point productivity start to matter and off the shelf solutions start to fail This is perhaps the third time I've posted this on HN, but what you describe is the circle of life for widely-used software projects. Large tech companies are not immune to it, resulting in frequent component rewrites, deprecations and almost-drop-in replacements that shuffle complex…

[deleted]

Re: “Clean” code, horrible performance

#550

Earlier quoted context omitted.

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time Unless we’re talking about specific compute-intensive websites, this is almost certainly network loading latency. Modern web browsers are very fast. Moderns CPUs are very fast. Common, random websites aren’t churning through “multiple seconds” of CPU time just to render.

I once optimised a SPA app that had to be really fast for usability reasons (industrial use), I replaced all the 'high level' JS patterns such as map, filter, and frontend framework things to use just if else and for loops and native dom manipulation, and it ended up more than 10x faster, each click would update the app in one frame, it was very noticeable. So yes CPU cycles do matter for websites, even with modern h…

Interesting that the speed up you saw was very similar to what the author got from the same kind of changes in C++.
Post reply on HN