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

461–470 of 932 posts

Re: “Clean” code, horrible performance

#461

Post by simplotek »

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?

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

If you can't recognize the percent where it matters a lot, clearly that percent does not exist and you're bothering about nothing.

I see a lot of talk about the importance of tuning Formula 1 cars in a world where everyone drives ford fiestas.

Re: “Clean” code, horrible performance

#462

Post by Arelius »

int_19h wrote: post #384
adamrezich wrote: post #316

Earlier quoted context omitted.

I'm not sure why you would say that—it's certainly a reason why some (not AAA) games are slow.

It should be noted that there were AAA games written in this fashion, and they were not slow. All method dispatch was virtual in UnrealScript, for example.

Well, for starters, many AAA games in Unreal had to have many core functions/classes rewritten from UnrealScript to C++ for performance reasons, where often not every call is virtual. Secondly, UnrealScript is not really a great example, since on-top of Unreal being notoriously on the slower-end of game architectures, and even Epic decided to drop UnrealScript.

And importantly, UnrealScript was designed in the 90's, when memory latencies were far less of problem.

Re: “Clean” code, horrible performance

#463

Post by Kukumber »

TeMPOraL wrote: post #382
ilyt wrote: post #284

Earlier quoted context omitted.

> The engineers in Turkey probably didn't value performance and efficiency Uh, no. It was corruption. They were standards, that worked, but people didn't do it, plain and simple.

Yeah, it's a bad and unnecessarily inflammatory (and arguably disrespectful) example. But the rest of the points GP makes are spot on. A "blame systems over individuals" version would be that the industry is externalizing bad performance onto users, damaging environment, causing frustration, wasting lives, and occasionally even actually killing people (shitty ER/hospital software comes to mind) - because there's no g…

> Yeah, it's a bad and unnecessarily inflammatory (and arguably disrespectful) example. But the rest of the points GP makes are spot on.

I agree, i apologies for the mistake, i can no longer edit the post unfortunately

Re: “Clean” code, horrible performance

#464

Post by xupybd »

jay_kyburz wrote: post #454
xupybd wrote: post #358

Earlier quoted context omitted.

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?

How replaceable is that person?

If they are a normal business admin they are very replaceable. So you don't have to make life easy for them unless they can justify the cost of doing so.

How busy are they?

If you have a 1 EFT position filled by an administrator that is only 60% busy then there is no cost in slowing them down until they're at 100% capacity. Then you might think about making life easier for them to avoid having to hire the next administrator. If people avoid doing their job because they don't like their tools that is a disciplinary matter. Time to find an administrator that can do the job required.

Re: “Clean” code, horrible performance

#465

Post by TeMPOraL »

bcrosby95 wrote: post #401
magicalhippo wrote: post #299

Earlier quoted context omitted.

Then again, thing's aren't in the critical path until suddenly they are. Regardless of scenario I will never willingly do a O(n^2) sort when writing new code. Just in case those 10 items suddenly turn to 10000 one day.

The moon doesn't fall into the ocean until it does.

Not a fair comparison :P.

The point is that the developers may think O(n^2) is fine because their toy use cases had n=10...100, but then actual users will try to use the software for n=10k, or n=100k, and then either waste their lives working with suddenly slow software, or look for alternatives.

I walked into a case like this the other day. I wanted to do a little semi-collaborative project planning. I found a nice tool, played with it for a moment, figured it has the functionality I need and it's fast enough. Then decided to do the actual plan. Once the number of entries in the system went from 10-20 to 30-40, I started to feel things get a little laggy. 50-60, more laggy. At this point I was committed, so I suffered the tool for couple of months, as its UI kept breaking when handling 100 entries. If I knew this would happen at the start, I'd look for something else. But instead, I walked into a hidden O(n^2) somewhere, that makes me hate the product with a passion now.

Re: “Clean” code, horrible performance

#466

Post by Arelius »

int_19h wrote: post #395
zelos wrote: post #40

Earlier quoted context omitted.

That does depend on how the abstraction is defined, of course. I once worked on optimising a 2D Canvas C++ class which had a nice top level virtual interface so you could replace it with a different implementation. It was also crazily slow because it defined: virtual void setPixel(int x, int y, int color) = 0; and then implemented flood fill etc in terms of that.

This isn't necessarily bad if all the other operations are also virtual. The idea is that you can quickly get something working (e.g. when porting) just by implementing setPixel(), and then gradually fill in other primitives with properly hardware-optimized versions. And you do need a virtual setPixel() in any case because some API client might need that one call.

I'm sorry, why do you need a virtual setPixel?

You can still easily get something working just by implementing setPixel without virtual dispatch, the linker has no problem inlining that call at compile time.

If some arbitrary API needs it to be virtual it's easy to implement the virtual call in just that specific case, instead of burdening your entire system with a virtual call that'll always be static in practice.

Re: “Clean” code, horrible performance

#467

Post by vkou »

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

Which is an excellent argument for why the WT team should have done some benchmarking, identified that they have a really dumb O(M*N) bottleneck in a critical part of their application (their rendering code), and optimized it.

It is not an excellent argument for why 'clean code' is not a better fit for the other 99% of their codebase.

Re: “Clean” code, horrible performance

#469

Post by e28eta »

GrumpySloth wrote: post #400
Aeolun wrote: post #351

Earlier quoted context omitted.

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

Even in C compiler will emit warnings for unhandled cases in switch statements as long as you don’t provide a default case (as you shouldn’t).

Depends on the type of code you’re writing. If your `switch` is tightly coupled to the code that defines the cases and they’ll definitely be changed in lockstep, a default is more likely to be harmful.

If your cases are defined externally, and you need to be forwards compatible, omitting a default is wrong.

The Swift language specifically added `@unknown default` for switching over enums.

Re: “Clean” code, horrible performance

#470

Post by DalekBaldwin »

p1necone wrote: post #293
yashap wrote: post #263

Earlier quoted context omitted.

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

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…

> Is Casey assuming the entire commercial software industry === Uncle Bob?

It's uncharitable to take Casey as making absolute blanket statements like that, but still, it would not be unreasonable for him to single out Uncle Bob in particular.

The Amazon rankings for Bob Martin's "Clean Code":

Best Sellers Rank: #5,338 in Books (See Top 100 in Books)

#1 in Software Design & Engineering

#2 in Software Testing

#4 in Software Development (Books)

Post reply on HN