“Clean” code, horrible performance • Hacker News Board

Re: “Clean” code, horrible performance

#231

Post by antoineMoPa » Tue, Feb 28, 2023, 9:38 PM UTC

rodrigobellusci wrote: post #222

mquander wrote: post #196

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…

Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.

Vue could also be an option, but I personally want to learn some Solid, as I see it could be preferred by the current mass of React frontend developers, more than Svelte and Vue. The syntax and philosophy of Solid looks closer to React, while having a stronger focus on performance.

Re: “Clean” code, horrible performance

#232

Post by jay_kyburz » Tue, Feb 28, 2023, 9:39 PM UTC

rodrigobellusci wrote: post #222

mquander wrote: post #196

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…

Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.

You should just try working directly in HTML.

Re: “Clean” code, horrible performance

#233

Post by morelisp » Tue, Feb 28, 2023, 9:40 PM UTC

chpatrick wrote: post #200

AnIdiotOnTheNet wrote: post #187

Earlier quoted context omitted.

> Look, most modern software is spending 99.9% of the time waiting for user input If that's true, why does it take forever to load and frequently fail to keep up with my input?

Often it's because of bad (quadratic) algorithms, not because the code isn't micro-optimized. For example: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

Accidentally super-linear algorithms happen a lot more when you hide stuff behind three layers of interfaces rather than seeing "oh, this uses a list instead of a set".

Re: “Clean” code, horrible performance

#234

Post by mabbo » Tue, Feb 28, 2023, 9:41 PM UTC

mquander wrote: post #196

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. 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, the developers will be asked to improve performance. Because in the end, economics is the driver, not performance.

Re: “Clean” code, horrible performance

#235

Post by jjeaff » Tue, Feb 28, 2023, 9:41 PM UTC

rstefanic wrote: post #148

thom wrote: post #74

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 progra…

When working with a larger code base, there will always be parts that you don't remember writing and you'll inevitably have to read the code to understand it. That's just part of the job/task, regardless of the style it's written in.

Of course any code requires some refresher at time, but the difficulty and time required to figure it out again is a spectrum that goes all the way down to the seventh circle of hell.

Re: “Clean” code, horrible performance

#236

Post by commandlinefan » Tue, Feb 28, 2023, 9:41 PM UTC

mquander wrote: post #196

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

Well, you can make things run even faster by hand-coding it in assembler... but performance isn't the reason we use high level languages. I agree with you that ignoring performance characteristics in favor of speed-to-market is an awful and pervasive practice in modern software development, but the linked article isn't talking about or making that case at all. He's saying that he can make his own custom object oriented C language that runs faster than C++ itself, but that's not news - people were saying that in 1995 (at least). The maintainability hit isn't worth it.

Re: “Clean” code, horrible performance

#237

Post by dgb23 » Tue, Feb 28, 2023, 9:43 PM UTC

pocket_cheese wrote: post #189

fredrikholm wrote: post #4

I've worked in projects where no one seemed to know SQL, where massive speed improvements were made by fixing very low hanging fruits like removing select * queries, adding naive indexes, removing N+1 queries etc. Likewise, I've worked in code bases where performance had been dreadful, yet there were no obvious bottlenecks. Little by little, replacing iterators with loops, objects/closures with enum-backed structs/ta…

Could you elaborate what you mean by "naive indexes"?

Not GP. But you can often anticipate where indexes have to go for common queries.

There might be some important colums like say a “status” or a “date”, which are fundamental to a lot of queries.

Or you have colums X and Y being used frequently or importantly in where clauses together, then that’s a candidate for composite indexes.

Stuff like that.

Re: “Clean” code, horrible performance

#238

Post by jstimpfle » Tue, Feb 28, 2023, 9:44 PM UTC

mabbo wrote: post #234

mquander wrote: post #196

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…

And depending on what you do, economics will let performance decide who wins. Git is probably one example. A different example, have you ever compared battery lifes of smartphones before buying one?

Re: “Clean” code, horrible performance

#239

Post by gongle » Tue, Feb 28, 2023, 9:44 PM UTC

cma wrote: post #134

TheFattestNinja wrote: post #111

Earlier quoted context omitted.

True, the example is simplistic, but that's just to make it fit within reasonable exposition. The author has in the past shown (elsewhere) how his techniques can actually make dramatic differences in more concrete examples (he rose to some Internet fame for building a performant shell that could actually handle larger outputs orders of magnitude better than most available alternatives). To me the interesting point is…

It was Windows Terminal he wrote something faster than. Windows terminal was doing a whole GPU draw call per character (at 2x standard terminal height, 160x25, it was as many draw calls as a AAA game).

No matter what design choices you argue for there are always ways to be an idiot about the implementation

Re: “Clean” code, horrible performance

#240

Post by flavius29663 » Tue, Feb 28, 2023, 9:46 PM UTC

One of the the points of "clean code" is to make it easy to find the hotspots and optimize those. Write the codebase at a very high level, plenty of abstractions etc. and then optimize the 1% that really needs it. Optimizing a small piece of software is not going again clean code, on the contrary, it re-enforces it: you can spend the time to optimize only what is necessary.