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

451–460 of 932 posts

Re: “Clean” code, horrible performance

#451

Post by nerdponx »

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 how much of that slowness is due to code that values "cleanliness" excessively? I bet that if you look at the source of nearly any application on your PC, it will be very much not clean on average.

Re: “Clean” code, horrible performance

#452

Post by int_19h »

Arnavion wrote: post #27
anonymoushn wrote: post #12

Earlier quoted context omitted.

I think "them" is someone named Robert Cecil Martin, but I'm not sure if this example from the video appears in his book. What compiler are you using that devirtualizes every class hierarchy? I suspect that Casey is using C++ so he may (unfortunately) have multiple translation units in his program.

>I suspect that Casey is using C++ so he may (unfortunately) have multiple translation units in his program. Yes, the video uses C++. Obviously if one compiles a library then the compiler has no way of knowing that other subclasses of `shape_base` do not exist. My point is that when compiling a binary as they are doing for their video, the compiler knows that there are no other subclasses that it needs to cater to. I…

Even when the target is an app, said app might be loading DLLs at runtime which may contain other subclasses.

The fundamental problem here is that C++ doesn't have a good abstraction to represent visibility of public types, since any other translation unit - even across the DLL boundary! - can re-declare the type and then derive from it. The only way to constrain visibility is to use anonymous namespaces, and that only works if the type can be confined to a single unit (that C++ compilers seem to ignore the optimization opportunities here in practice perhaps indicates just how rare this actually is).

Re: “Clean” code, horrible performance

#453

Post by sangnoir »

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…

> 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 complexity up or down the stack.

Step 1: Developer is fed up by how slow/bloated current incumbent is, so they write a fast, lean and mean project that solves their problems

Step 2: The project becomes popular on its merits, rakes in stars on Github as people discover how awesome it is

Step 3: Users start discovering limitations for their use cases, issues and pull requests pour in

Step 4: Thousands of PRs later, the project is usable by most people and has "won". It is now the incumbent, but no longer is as fast as it once was, but it also ships functionality catering to many niche needs

Step 5: Go to step 1

Re: “Clean” code, horrible performance

#454

Post by jay_kyburz »

xupybd wrote: post #358
jiggawatts wrote: post #334

Earlier quoted context omitted.

> CPU cycles are much cheaper than developer wages. Please just stop with this. It's plainly false. At $dayjob I recommended some simple database query tuning that 1 developer applied in their spare time. This improved performance from 9 seconds per page to 500 milliseconds per page. That customer wanted to use auto-scale to expand capacity (nearly 20-fold!) to meet the original requirements, which would have cost ab…

In this case you have massive scale so a small amount of developer time can equate to a big reduction in CPU cycles. Those are the constraints you work with. Those are the business problems you are solving. So yes this was justified. It was justified on the numbers. My point is that your job is only to tune performance iff there is a solid business case for it. I spent a week reducing a pages load time because the bu…

>My point is that your job is only to tune performance if there is a solid business case for it.

I think its very very hard to put a cost on performance.

A few seconds here or there is very draining on people. How do you measure if people are avoiding doing things, or putting off work because their tools are janky. How do you measure how much time people spend complaining about how slow their computer is?

Re: “Clean” code, horrible performance

#455

Post by whstl »

ilyt wrote: post #258
ajmurmann wrote: post #190

Earlier quoted context omitted.

Don't forget the 90% of the processing time that it's waiting for a DB response

Eh, that heavily depends on language and dataset you're working with. I've seen "simple" data with some fat thing like RoR on top of it having 10x the latency of the underlying database after all the ORMing.

I have a similar experience. Also, for the longest time Rails was also incredibly slow at generating JSON, of all things. JBuilder [1] was a few orders of magnitude slower than using .to_json directly or other libraries.

[1] https://github.com/rails/jbuilder, maintained by DHH and the Rails team. AFAIR, the "official" JSON serialization DSL.

Re: “Clean” code, horrible performance

#456

Post by simplotek »

loup-vaillant wrote: post #342
simplotek wrote: post #250

Earlier quoted context omitted.

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a textbook example of an hyperbolic fallacy. There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time". This blend of specious reasoning is the reason why the first rule of software o…

I realised when I implemented EdDSA for Monocypher that optimisations compound. When I got rid of a bottleneck, I noticed that another part of the code was the new bottleneck, and some of the optimisations compounded multiplicatively . It took many changes before I finally started to hit diminishing returns and stop. All while restricting myself to standard C99, and trying fairly hard not to spend too many lines of c…

> 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? Odds are, not at all.

Re: “Clean” code, horrible performance

#457

Post by julik »

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…

What if you have a growing team of N people, and they need to be able to add shape subclasses / new shape logic all the time? As with anything this is a tradeoff. Often having decoupled code is more important than raw performance.

Re: “Clean” code, horrible performance

#459

Post by eyelidlessness »

TeMPOraL wrote: post #324
jimbob45 wrote: post #291

Earlier quoted context omitted.

Well said. The aphorism "Premature optimization is the root of all evil" is meant to mean "Build it right first, then optimize only what needs to be optimized". There's really no need to start cooking spaghetti right off the bat. Clean code with some performance tweaks will be more maintainable in the long run without sacrificing performance.

Casey's implied point is that clean code is already sacrificing performance from the start. And of course real life tells us that those "performance tweaks" will never happen. There is this popular wisdom that security must be designed for from the start, and cannot be just added after the fact. Performance is like that too, except worse, because you actually can add security after the fact - worst-case, you treat th…

> And of course real life tells us that those "performance tweaks" will never happen.

I seldom wish I could post images on here, but I really would love to share a photo of the surprise coffee mug my work sent me, with a screen cap of a completely obliterated Y axis on a performance monitoring graph. Granted I don’t get to spend all my time hunting optimizations, but some teams/orgs/companies do very much value performance very explicitly.

Edit: and I’m definitely not a game dev. Though I’ve been itching to borrow some game dev techniques that are quite applicable for my domain (particularly ECS, entity component systems, which I suspect have far broader applicability than their adoption outside of game dev).

Re: “Clean” code, horrible performance

#460

Post by xupybd »

alfalfasprout wrote: post #446
xupybd wrote: post #219

>It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier. Our job is to write programs that run well on the hardware that we are given. If this is how bad these rules cause software to perform, they simply aren't acceptable. That is not our job! Our job is to solve business problems within the constraints we are given. No…

The problem is I think you're also disagreeing with yourself in a way. > That is not our job! Our job is to solve business problems within the constraints we are given. No one cares how well it runs on the hardware we're given. They care if it solves the business problem. Look at Bitcoin, it burns hardware time as a proof of work. That solves a business problem. Cost is a business problem. It is a constraint. The pro…

> Cost is a business problem. It is a constraint

I 100% agree. What I'm trying to get across is that you have to identify the cost to justify the performance tuning. If the cost of the tuning is greater than the cost incurred by not doing you might not want to do it.

What are your actual costs and how do they line up? Are you writing ML and big data then processing costs are huge. You can probably win by spending money on developer time to reduce processing costs. On the opposite end of the scale are you writing CRUD for a small business, then the development costs are likely to outweigh any costs from inefficiencies in the applications code.

To me the article read as if our job was to make every bit of code as fast as possible. I think we should only spend time on code that meets the greater goals of the system it operates in.

If you identify that run time is a cost then you have to identify what part of the code is the bottle neck and fix that. Then you have look back to see if any more improvements will be worth the time invested.

Post reply on HN