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

351–360 of 932 posts

Re: “Clean” code, horrible performance

#351

Post by Aeolun »

jiggawatts wrote: post #322
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…

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.

Re: “Clean” code, horrible performance

#352

Post by rrobukef »

the-smug-one wrote: post #295
FooBarWidget wrote: post #185

Earlier quoted context omitted.

Not only time to market, but also maintainability. In non-performance-critical areas, it's pretty important that when the original dev team leaves, new hires can still fix bugs and add features without breaking things.

I don't see how the code snippets presented are less maintainable.

I do. Because I was asked to add a convex polygon and calculate its area. And now the shape_union must be rewritten from scratch.

... And maybe we want set-operations in the future...

Re: “Clean” code, horrible performance

#353

Post by kyralis »

jiggawatts wrote: post #322
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…

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

"Easier to write, easier to read" is the part that's wrong with that advice.

It absolutely is, on toy problems like the one described in the article.

It very frequently is not when embedded in much larger domains as part of large projects maintained over years by teams.

Re: “Clean” code, horrible performance

#354

Post by tyre »

bob1029 wrote: post #241
kaba0 wrote: post #166

Earlier quoted context omitted.

One can reasonably well guess/know the expected input sizes to their programs. You ain’t (hopefully) loading your whole database into memory, and unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop, that’s just not how most programs look like. If it is, then you should design for it, which may even mean changing programmi…

> unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board. We should try to steal more ideas from different domains instead of treating them like…

> If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board.

Sure but it’s a question of tradeoffs.

If the wall-clock-optimized version creates a bus count of 1 for that domain or is difficult for a dozen engineers to iterate on, then that could be worse for the business and users.

Should we want better software? Yes. Should we learn from other domains? Absolutely. But we should ultimately optimize for the domain we’re in, and writing much product-focused software is ultimately best optimized for engineering team and product velocity.

Another example: would most software benefit from formal verification? Yeah, I guess, but the software holistically—as a thing used by humans to solve problems—might benefit considerably more from Ruby.

Re: “Clean” code, horrible performance

#355

Post by loup-vaillant »

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…

> there is no way to sandbox your app so it goes faster.

In a number of cases you actually can. Casey demonstrated it in his Refterm lectures, it's caching. You still call the slow thing, but at least you don't call it as often because you have that layer of caching to partially insulate you from its poor performance. Good luck if you have to deal with cache invalidation, though.

Re: “Clean” code, horrible performance

#356

Post by [deleted] »

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…

[deleted]

Re: “Clean” code, horrible performance

#357

Post by Turskarama »

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…

This is not my experience at all, at my org we always write it the simple way first, and if it needs more performance after the fact then we always add the performance. User friendliness always comes first. This includes not waiting 20 seconds for a db query that could be rewritten to happen in 1 second, but it also means not waiting a month for a bugfix which could happen in a day with maintainable code.

Re: “Clean” code, horrible performance

#358

Post by xupybd »

jiggawatts wrote: post #334
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…

> 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 busines saw the load times as a problem for customer acquisition. The cost of my time was justified. Meanwhile we had a task that for 6 years took over an hour to run. I optimized it to take less than a second. That change has offered zero business value and was a waste of time. It runs periodically on a server that is most often idle. There was no justification for that work, other than it taught me to align my efforts with the business.

CPU cycles are much cheaper than developer hours. But yes, if you have enough of them yes they will cost more than a developer.

Re: “Clean” code, horrible performance

#359

Post by adamrezich »

saidinesh5 wrote: post #32
vore wrote: post #19

Earlier quoted context omitted.

The shapes example is pretty contrived so I don't really have an opinion on it either way. But imagine you have something like a File interface and you have implementations of it e.g. DiskFile, NetworkFile, etc., and you anticipate other implementors. Why would you do anything other than have a polymorphic interface?

I think the shapes example is more of a dig at various game engines where you end up with a long trees of inheritance (physicsbody -> usercontrollable physics body -> renderable user controllable physics body etc..) as opposed to the recent trend of using something like an Entity Component System. Also I think he isn't specifically against "clean code" but how the first tool used by various "clean code advocates" see…

I wish he would've gone a bit more into why people reach for polymorphism instead of a struct with a variant enum: because it's how OOP is taught, and how it easily maps to human understanding of most problem spaces. like you're making an RPG, so you make an Item class, and then you make Armor and Weapon subclasses, and then you make Helmet/Chestplate/Leggings/Shoes and Sword/Polearm/Axe/Mace/Staff subclasses, etc. etc., just because it fits your mental model of the problem, when in actuality, you could've totally avoided all of that complexity, and the ensuing boilerplate, just by sticking it all in one struct and calling it a day. this is not always the solution, but more often than not it is.

Re: “Clean” code, horrible performance

#360

Post by Turskarama »

heisenbit wrote: post #281
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…

How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?

Testing, do you not do testing? Use the software. If it seems slow drill down and find the critical path and optimize it.
Post reply on HN