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

281–290 of 932 posts

Re: “Clean” code, horrible performance

#281

Post by heisenbit »

simplotek wrote: post #250
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…

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

Re: “Clean” code, horrible performance

#282

Post by scotty79 »

jupp0r wrote: post #172

There's a tradeoff. Engineering time is expensive. Machine time can be expensive too. We need to optimize these costs by making most code that's not performance relevant easy to read and then optimize performance critical code paths while hiding optimization complexity behind abstractions. Either extreme is not helpful as a blanket method.

User time is expensive too.

Re: “Clean” code, horrible performance

#283

Post by danuker »

dgb23 wrote: post #265
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…

Well yes it kind of is? Everyone solves problems. We solve problems with computers. And we use them because they’re autonomous, remember exact details and are very fast and reliable. There’s of course some level of good enough. We don’t write ad-hoc scripts in assembly. But to say dev time is more expensive than computer time only makes sense if programs are actually fast. Fast, reliable feedback loops matter. Consis…

> and are very fast and reliable.

Among the most popular languages is Python. It is popular in spite of its bad performance, high memory use, and lack of CPU multithreading.

And it is heavily ran on servers.

Why? Because running Python apps is still much cheaper than hiring humans to wait for calls or manage e-mails.

Humans are valuable. They should not be working on easily automatable problems.

The bottleneck is automating AT ALL, rather than automating with a low machine cost. Only at huge scale (i.e. Big Tech with billions of daily events) does it warrant to optimize the code.

Of course, assuming you have a sane computational complexity. If you don't, it doesn't matter which paradigm you use.

Re: “Clean” code, horrible performance

#284

Post by ilyt »

Kukumber wrote: post #214
vore wrote: post #15

This guy is so dogmatic about it it hurts. I would argue that clean code is a spectrum from how flexible vs how rigid you want your abstractions to be. If your abstractions are too flexible for good performance, dial them back when you see the issue. If your abstractions are too rigid for your software to be extendable, then introduce indirection. We can all write code that glues a very fixed set of things end to end…

0 responsibility developers you have Japan infrastructure, and you have Turkey infrastructure 6.1 quake in Japan = nothing destroyed 6.1 quake in Turkey = everything collapses The engineers in Turkey probably didn't value performance and efficiency It's the same for developers, you choose your camp wisely, otherwise people will complain at you if they can no longer bear your choice You act like innocent, but your cod…

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

Re: “Clean” code, horrible performance

#285

Post by itake »

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…

I think there are some ethical aspects of this that are missing.

Writing in efficient code has an environmental impacts and a human impact.

I still lean heavily towards clean code, because clean is easier to Grep and bugs have a much higher impact to my career, but efficiency imho should be addressed in the language or compiler, not in the code.

Re: “Clean” code, horrible performance

#286

Post by eropple »

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?

In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".

Re: “Clean” code, horrible performance

#288

Post by jay_kyburz »

dgb23 wrote: post #205
fredrikholm wrote: post #4

I've worked in projects where no one seemed to know SQL, where massive speed improvements were made by fixing very low hanging fruits like removing select * queries, adding naive indexes, removing N+1 queries etc. Likewise, I've worked in code bases where performance had been dreadful, yet there were no obvious bottlenecks. Little by little, replacing iterators with loops, objects/closures with enum-backed structs/ta…

I can very much relate to this. Just taking the little bit of time to think about what the computer needs to do and making a reasonable effort to not do unnecessary stuff goes a long way. That 2x-50x factor is in fact very familiar. That’s something loading in a second rather than in a minute, or something feeling snappy instead of slightly laggy. And it matters much more than people say it does. The “premature optim…

One thing I find frustrating in game development, is we often put off optimization until the end of the project when we know we are happy with the game. But that means _I_ have to live with a slow code base for 2 years.

It takes 19 seconds for the main menu to load when you push play on our current game in Unity. It's killing me.

Meanwhile in my lua side project, its less than a second.

Re: “Clean” code, horrible performance

#289

Post by datavirtue »

gary_0 wrote: post #277
PragmaticPulp wrote: post #216

Earlier quoted context omitted.

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time Unless we’re talking about specific compute-intensive websites, this is almost certainly network loading latency. Modern web browsers are very fast. Moderns CPUs are very fast. Common, random websites aren’t churning through “multiple seconds” of CPU time just to render.

I just loaded cnn.com while looking at the CPU utilization graph: 50% use of my 8 logical cores at 4.5GHz for the better part of a second. So no, it's not just network latency. Doing multiple parallel network requests, parsing, doing layout and applying styles, running scripts, decoding media... a modern website and browser devours CPU time.

So those who visit Fox and CNN are helping to destroy the planet. Or is it the developers fault? Can't be the developers.

Re: “Clean” code, horrible performance

#290

Post by eropple »

jay_kyburz wrote: post #232
rodrigobellusci wrote: post #222

Earlier quoted context omitted.

Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.

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

Post reply on HN