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

651–660 of 932 posts

Re: “Clean” code, horrible performance

#651

Post by piaste »

Ygg2 wrote: post #585
andyferris wrote: post #389

Earlier quoted context omitted.

Many languages provide unions or sum types along with exhaustiveness checking to make this very easy (frequently not OO-inheretence based languages though).

What happens if library user wants to extend functionality? They can't inject their code into the library.

Yeah, it's very awkward. Your best option is to leave a 'hole' case where someone may provide a 'data type' set of functions satisfying an interface, and the library author simply calls them. Effectively you're adding an OO escape clause, but it's ugly and will break user code when you add more functions and grow the interface.

Conversely, in a codebase organized by objects it's not clean to add an extra method to the base class and each subclass. You have to write an external function and switch over every known subclass inside it, which is also very ugly and will also break when you add more subclasses.

The two designs are actually the duals of each other. Someone compared it to rows vs columns and it's a great comparison.

In OO, the methods are columns and each new row is a new subclass implementing them.

In FP, the types are the columns and each new row is a function that switches over the possible types.

Re: “Clean” code, horrible performance

#652

Post by nottorp »

simplotek wrote: post #628
xtian wrote: post #528

Earlier quoted context omitted.

So why do 99% of real world applications run like garbage? What’s the culprit?

> So why do 99% of real world applications run like garbage? If you're really interested in the impact of performance issues on everyday life, you need to provide concrete examples instead of putting up unverifiable strawmen. The truth of the matter is that 99% of real world applications run just fine, and it doesn't pay off to invest in shaving milliseconds here or there. Would it be desirable to have a magic wand t…

You basically waste millions of seconds of users' lifetime instead :)

Not to mention that web apps redrawing everything whenever they feel like it can almost give motion sickness, lead to clicks on the wrong things etc.

Yeah, but users' time is worthless.

Re: “Clean” code, horrible performance

#653

Post by citrin_ru »

yashap wrote: post #263
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…

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…

Write slow code now, profile and optimize later is how we got all slow software because second step - optimization practically never happens in my experience.

Along with the heuristic that hardware and electricity are cheap, developers are expensive. That's probably why managers in my experience almost never ask developers to optimize slow code - they believe it would be cheaper to use more hardware if this fixes the problem (in some areas like HFT or GamDev more hardware is not the answer so optimization do happen). In rare cases I've seen optimization being done initiative always come from IC (who knew that the code could work fast / use less resources).

So nowadays writing code I assume that it never will be optimized later and try to do less dump stuff from the beginning.

Re: “Clean” code, horrible performance

#654

Post by cturner »

magicalhippo wrote: post #299
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…

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.

"Regardless of scenario" limit your options.

If you are shipping a binary to your users that will never be able to get updates, your cautiousness would be justified. There are other situations where it will needlessly limits options.

There are situations where I have knowingly written O(n^2) or worse, and put a # xxx dragons marker by it. Quick to write, leave my options open, keep my momentum on the problem I care about.

I will grep for xxx issues at some later time. I may end up throwing out the code before that happens. If I hit big-o issues before then, I can refactor.

I once had a system where the important problems turned out to be a series of IO bottle-necks - nothing to do with computation - but that was obscured because good sense had been burnt at the altar of compute efficiency.

Re: “Clean” code, horrible performance

#655

Post by Olreich »

Ygg2 wrote: post #585
andyferris wrote: post #389

Earlier quoted context omitted.

Many languages provide unions or sum types along with exhaustiveness checking to make this very easy (frequently not OO-inheretence based languages though).

What happens if library user wants to extend functionality? They can't inject their code into the library.

If this is going to be a library where that’s a desirable feature, architect it for that feature. In the example, one easy way would have the coefficient table be expandable/replaceable. If you really need to run arbitrary user code, then write an interface that the user will conform to and call their code. You don’t even need OOP support to do that easily, just typed function pointers.

Re: “Clean” code, horrible performance

#656

Post by DeathArrow »

zamalek wrote: post #596
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…

Exactly. The problems of software performance come from decades of poorly/quickly executed evolutionary change resulting in bad systems design. It's all an new abstraction over an older abstraction over an even older abstraction, because some old application still needs to be supported (something Casey has likely never had the problem of worrying about in game development). Game developers have the luxury of starting…

I am a developer who worked on embedded, desktop apps, mobile apps, games and now on large microservice based application. A developer is a developer and can move from one kind of application to another.

I find what Casey says in his videos to be true. And I though about that stuff before I even watched his videos, which are excellent.

However, I started not to care. I don't want to start fights inside the company, especially fighting alone against many OOP cultists. There's not my money at stake, so if companies as a whole decide for OOP, clean code, SOLID, design patterns, abstractions on top of abstractions, making the code bases giant pile of junks while degrading performance, I am not going to go against the crowd.

Code that I write for myself is quite different than code I write for my employers.

I just hope that the industry as a whole will wake up from the whole OOP nightmare.

Re: “Clean” code, horrible performance

#657

Post by dgb23 »

danuker wrote: post #437
dgb23 wrote: post #315

Earlier quoted context omitted.

I think you’re right what you said. But the gist of the video doesn’t disagree at all. In fact the resulting code was very clear, easy to write and understand. He got a 15x improvement by removing indirection and OO cruft. I don’t think he’s saying “don’t use language X” here, but rather “don’t make it harder for yourself and the computer”.

But it does disagree. Python is a dynamic language where essentially everything is indirect (an object). Hardcoding types and methods (so they compile to simple/fast machine code as the video proposes) takes away flexibility (but you can do that with Cython by the way, but it is not nearly that popular).

I don’t know/use python. But I assume that it has hasmaps and vectors that are backed by something performant and possibly JITed?

The table driven, static dispatch approach Muratori isn’t necessarily “hard coded” in the general case. It’s just data driven, or table driven as he puts it. It’s not less flexible as you can easier add (append!) new cases.

In fact it reminds me of how I do it in higher level languages like JS and Clojure.

Of course we’re paying a substantial performance tax when using higher level, dynamic languages. We’re paying that tax in order to get very tangible benefits.

But we can still program in a way that is data oriented, simple and easy to work with by the compiler and runtime (JIT).

Re: “Clean” code, horrible performance

#658

Post by resonious »

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…

Sure I leave apps sitting around waiting for my input quite often. But then when I do start inputting stuff, they lock up, fail to respond to my inputs, show me loading screens, blank screens, delayed responses, and otherwise waste my time. Pretty silly given how much money I pay for the hardware.

Re: “Clean” code, horrible performance

#659

Post by nottorp »

eropple wrote: post #290
jay_kyburz wrote: post #232

Earlier quoted context omitted.

You should just try working directly in HTML.

I look forward to returning to the days where everybody wrote their own slightly-to-significantly-wrong state management tooling while being distracted by the minutiae of DOM wrangling. That was a good time. (It was not. It was why I stopped doing frontend work.)

Perhaps ... it's the underlying platform's fault?

Re: “Clean” code, horrible performance

#660

Post by moonchrome »

citrin_ru wrote: post #653
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…

Write slow code now, profile and optimize later is how we got all slow software because second step - optimization practically never happens in my experience. Along with the heuristic that hardware and electricity are cheap, developers are expensive. That's probably why managers in my experience almost never ask developers to optimize slow code - they believe it would be cheaper to use more hardware if this fixes the…

If it doesn't happen then it doesn't matter.
Post reply on HN