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

881–890 of 932 posts

Re: “Clean” code, horrible performance

#881

Post by mtrower »

xupybd wrote: post #532
jiggawatts wrote: post #510

Earlier quoted context omitted.

> CPU cycles are cheap But people aren't. Any code that "makes people wait" is wasting people's time. The only way to make code take less time is to optimise it, because capacity != latency. You can't get a 20 THz processor. You can buy more capacity, but you can't buy more speed! At FAANG scale, it's common to hire "top" developers at hugely expensive annual total comp to tune stdlib code like "string" for just 1-2%…

>I can't think of a typical business scenario where compute and/or associated per-core-licensing costs can be blindly disregarded with a flippant statement like "developers are expensive and infrastructure is cheap". Say you're a small business with an in house server rack. Not a software company but say a manufacturing business. Not enterprise scale, smaller. You have 1 development resource. It turns out the ETL ser…

Don't forget your electricity costs, A/C costs, hardware maintenance costs... these are often overlooked, but are not nothing. You've added permanent recurring expenses to avoid your one-time developer fee.

Yes, sometimes this might make sense --- if the dev fees are going to be exorbitant, or if you just can't afford to pull a dev off a project to work on it. Other times, it makes more sense to pay the dev...

You keep saying, CPU cycles are cheaper than developer hours, but this is nonsensical without quantities attached to each. How many CPU cycles, on what kind of machines? How many cycles do those machines have to spare? What's the performance per watt? How many developer hours at what kind of salary? There's way too much missing info to be making such a statement.

Re: “Clean” code, horrible performance

#882

Post by mtrower »

xupybd wrote: post #464
jay_kyburz wrote: post #454

Earlier quoted context omitted.

>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 avoi…

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

That is a mentality which is too horrifiying to find proper words to describe.

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

It's human nature to avoid difficult things. Discipline only goes so far; it happens subconsciously.

And anyway, small inefficiencies add up to mountains, but it can be hard to see what's going on when everything is just pebbles everywhere.

Re: “Clean” code, horrible performance

#883

Post by mtrower »

xupybd wrote: post #477
alfalfasprout wrote: post #449

Earlier quoted context omitted.

OK but... computationally heavy code in Python isn't generally really running in Python. Almost all of it either calls out to optimized C/C++/Fortran (eg; Numpy which in turn calls BLAS+LAPACK) or do that or some other separate compilation (eg; what ML libraries do with XLA, etc. or cython). Sure, python web servers are a thing. Heck, we use them a fair bit. But it's a deliberate decision from the start where it make…

>But it's a deliberate decision from the start where it makes sense to use it for that purpose. Exactly that! There is a time and a place for performant code but it's not the only metric we need to take into consideration. Sometimes you're better off using the slower tool or algorithm as it improves things on a dimension other than performance.

> There is a time and a place for performant code but it's not the only metric we need to take into consideration.

Of course not. But then, nobody is really complaining about apps they think are fast enough. The problem is, when something is noticeably slow, you complain about it, file reports etc, and are met with stiff resistance.

What's important is not that you make the machine go as fast as it can possibly go at all times. What's important is to know how fast it can go, so that you're aware of just exactly how much you're leaving on the table. The actual amount in most cases, would, I expect, surprise most people...

Re: “Clean” code, horrible performance

#884

Post by badsectoracula »

Taniwha wrote: post #852
badsectoracula wrote: post #392

Earlier quoted context omitted.

> instead of loading the address and jumping to it push the address then return to it I remember doing that in a code generator ages ago because it was easier than calculating the jump offset :-P

every subroutine return after that would be miss-predicted

FWIW i wasn't trying to make an optimizing compiler, i was experimenting with replacing an interpreter for a scripting language with a JIT, so even bad native code was still faster than the interpreter :-).

It wasn't really used anywhere, eventually i decided to keep the interpreter and move any complex logic in C which ultimately was the simpler approach (and which has been my take on scripting languages for years now: use scripting languages for the "what" and native code for the "how").

Re: “Clean” code, horrible performance

#885

Post by gjulianm »

trashtester wrote: post #770
gjulianm wrote: post #698

Earlier quoted context omitted.

Well, for starters, Amdahl's law exists. If you use design patterns that are 10x slower on a code path that takes only 0.5% of the execution time your application ends up 0.55% slower. And the profiler never tells you how faster can a code path be. It just tells you where are you spending most of your time so you can put the effort where it matters.

This is precisely the kind of situation where it's imperative to consider performance before starting to build a new system. When you hit Amdahl's law, it's because you (or someone else) has made decisions about the high level design/patterns to use in a system. To remove such bottlenecks, you may have to scrap the entire project and start over. For the inner loops, it's perfectly fine to leave most of the optimizati…

I mean, you always hit Amdahl's law, and the point is that most often the time limits are not that related to the architecture. Let's say you do these "10x slower patterns" in a backend application, in the part where the DB model gets translated to a response to give the client... Yeah, maybe that pattern is slower but most of the time of the response is spent on the network and the DB response.

I do agree that overall design needs to fit performance requirements but for the most part that has nothing to do with "clean code" patterns.

Re: “Clean” code, horrible performance

#886

Post by wellanyway »

onion2k wrote: post #247
mquander wrote: post #196

Earlier quoted context omitted.

> 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 performance calculation software then sure, go crazy, get those improvements. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because o…

For what it's worth, less than 4% of websites use React (approximately 4% use any JS framework) . If you believe the web is slow because of React you are wrong. It's not even due to JS.

> It's not even due to JS.

Do enlighten us then, what is it due to?

Re: “Clean” code, horrible performance

#887

Post by dogen »

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…

dude then why does most modern software feel like shit even on high performance systems?

Well written video games, the kind of thing Casey works on usually, beat the hell out of basically any other category of software in terms of user responsiveness. At least of all the software I use regularly.

Re: “Clean” code, horrible performance

#888

Post by teworks »

aforwardslash wrote: post #846
AlchemistCamp wrote: post #749

Earlier quoted context omitted.

> “Ideally, a game is a one-off effort where you write a piece of code and if you're lucky, you won't have to touch it again.” Ideally a game pulls in over a billion dollars per year, every year for over a decade. Think World of Warcraft or Fortnite , not Flappy Bird.

And the amount of money changes the fact that the core engines are written as a one-off effort how, exactly? Updates to the scripting engine to fix play-ability issues and content updates aren't really heavy software refactoring. Sure, there are usually some actual code bugfixes on the initial releases - and more often than not - related to someone implement some really clever trick that raises an exception on some c…

If you think that, you're not familiar enough with modern games as a service. Fortnite lives on the latest version of Unreal Engine, and Unreal Engine changed a lot from the initial Fortnite development until now with many new features, rewritten parts, and major refactoring of other parts. It's huge and constantly evolving, so it is similar to, i.e., browsers.
Post reply on HN