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

701–710 of 932 posts

Re: “Clean” code, horrible performance

#701

Post by Zvez »

whstl wrote: post #433
rileyphone wrote: post #346

Earlier quoted context omitted.

Not the case if your program is spending most of its time waiting, which is typical these days.

Not necessarily in the general case. If the program is a single user, locally ran program, then sure. If it's some sort of backend or distributed service, this is just wasted performance that can be used to serve more users. Virtually every distributed service built today is able to take advantage of this. With a non-pessimal design, not only you are able to pay less money on servers in the long term, you're also abl…

using 'unclean' code practice will increase development costs. And more importantly - maintainability of such code.

>Virtually every distributed service built today is able to take advantage of this

most of built today services can take much more advantage in using better system design practices.

Re: “Clean” code, horrible performance

#702

Post by Fell »

> Our job is to write programs that run well on the hardware that we are given.

I actually believe "the hardware that we are given" is the entire root of the problem.

Most programmers work and test using whatever hardware is current at the time, but this is makes them blind to possible performance issues.

Take whatever you're working on, and run it on the hardware of 5-10 years ago. If you still have a good experience, you're doing it right. If not, you should probably stop upgrading developer machines for a while.

Whatever your minimum hardware requirements are should determine your development machines. This way, you will naturally ensure your low-end customers have a good experience while your high-end customers will have an even better experience.

My game studio has been doing this for years. It saves money for expensive hardware, it prevents performance issues before they arise and it saves developer time for not having to overthink optimization.

Re: “Clean” code, horrible performance

#703

Post by Akronymus »

chenglou wrote: post #520
TeMPOraL wrote: post #465

Earlier quoted context omitted.

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…

It's more than that. The way black box composition is done in modern software, your n=100 code (say, a component) gets reused into a another thing somewhere above, and now you're being iterated through m=100 times. Oops, now n=10k Generally, Casey seems to preach holistic thinking, finding the right mental model and just write the most straightforward code (which is harder than it looks; people get distracted in the…

> The way black box composition is done in modern software, your n=100 code (say, a component) gets reused into a another thing somewhere above, and now you're being iterated through m=100 times. Oops, now n=10k

That doesn't seem quite right. as 100 * (100^2) <<<<< 10000^2

Re: “Clean” code, horrible performance

#704

Post by phtrivier »

josephg wrote: post #330
rwalle wrote: post #292

Earlier quoted context omitted.

Exactly. The webpage is probably asking for resource from 10 different servers and one of them is a bit slower than the others, and the page rendering itself likely doesn't take very long.

No; I have no idea why its so slow. Its kind of hard to tell - I guess I could use wireshark to trace the packets. But who cares? At least one of these things is true: - It makes horribly inefficient use of my CPU - It needs an obscene number of network round-trips to load - One of the network servers that discord needs to open takes seconds to respond to requests This isn't a new problem. Discord always takes about…

> The only reason most software runs slowly is because the developers involved don't care enough to make it run fast.

There is truth to that, but also:

* some of them would care if they knew what was possible with reasonnable effort (that's what Casey is trying to address. So far in the course i'm not really seing much that I could apply to the kind of code I write, sadly - but I'm hoping to learn stuff.)

* it's very likely that making performance-aware or optimized code takes just a tad longer than not doing it, and time-to-ship is valued much higher than time-to-run in most industries (this is the point I think Casey is overlooking, or at least not addressing enough. I don't know if it's by design - maybe he disagrees with the trade-off entirely - or if he's biased towards one of the few industries where time-to-run is crucial.)

Re: “Clean” code, horrible performance

#705

Post by hdhrufjdi »

piaste wrote: post #661
noobermin wrote: post #634

Earlier quoted context omitted.

How so? What loop isn't "tight"? EDIT: To expand on this, why is modern software slow? The reason is because people, thinking their code isn't a bottle neck or performance doesn't matter but adherence to the right abstractions is, they write slow code and call backs thinking everything just happens immediately, with layers of abstractions, and those little innocent steps add up when every piece of code written today…

The kind that runs once and then waits geological ages to hit the next iteration. For example: while (command != 'quit') { command = readline() handle(command) }

Handle(command) runs in another loop at the same time, the scheduler.

Re: “Clean” code, horrible performance

#706

Post by phtrivier »

Gluber wrote: post #259
stunpix wrote: post #150

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere "? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method…

I agree with your sentiment. But those things exist (not that that validates the authors argument) and I still shake in terror when during covid I was asked to take a look at a virus spread simulation (cellular automaton) that was written by a university professor and his postdoc team for software engineering at a large university that modeled evey cell in a 100k x 100k grid as a class which used virtual methods for…

In all fairness to them, "simulating many stuff interacting with each other" is the poster child of OO. It's just, that, well, it's not how CPU works.

Then again, at some point we had "Lisp machines", maybe some day there will be a computer architecture where memory / computations patterns are adapted to massive simulation - rather than shoehorning on existing architecture.

And those will fail just as miserably as Lisp machines.

Re: “Clean” code, horrible performance

#707

Post by amelius »

badsectoracula wrote: post #371
fvdessen wrote: post #319

Earlier quoted context omitted.

If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler will not give you any idea that it could be still 10x faster.

If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The…

No, if one day you decide to run it on a less capable CPU, it's nice if the optimization work has been done.

Re: “Clean” code, horrible performance

#708

Post by darkwater »

ajmurmann wrote: post #190
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…

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

Yes, because of some clean and readable way (for the developer) the code uses to interact with the DB...

Re: “Clean” code, horrible performance

#709

Post by Cabronavirus »

jiggawatts wrote: post #326
stunpix wrote: post #150

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere "? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method…

> The real situation: a virtual method is called only a few hundred times and is barely visible in profiling tools. The reality is that the entire Java ecosystem revolves around call stacks hundreds of calls deep where most (if not all) of those are virtual calls through an interface. Even in web server scenarios where the user might be "5 milliseconds away", I've seen these overheads add up to the point where it is…

[dead]
Post reply on HN