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

661–670 of 932 posts

Re: “Clean” code, horrible performance

#661

Post by piaste »

noobermin wrote: post #634
rileymat2 wrote: post #558

Earlier quoted context omitted.

You dropped the word "tight", it is important.

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

Re: “Clean” code, horrible performance

#662

Post by hallqv »

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…

Great reply, thanks for sharing your experiences!

Re: “Clean” code, horrible performance

#663

Post by nottorp »

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…

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something.

So why isn't my browser at 0% CPU when IN THE BACKGROUND then?

Re: “Clean” code, horrible performance

#664

Post by mtrower »

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…

> the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing

Who was talking about a single millisecond here?

I notice, broadly, two types of people who engage in these arguments.

1> OMG, computers are thousands of times faster than they were a decade ago, why is everything not lightning fast? Why are so many things slower than they were back then? Why is my chat program eating 2GB(!) of RAM?

2> Because we're busy writing six billion features on our Nth iteration of this problem space, we can't be bothered to shave a few millis bro!

And they just talk past each other.

Re: “Clean” code, horrible performance

#665

Post by citrin_ru »

moonchrome wrote: post #660
citrin_ru wrote: post #653

Earlier quoted context omitted.

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.

It doesn't matter in a sense that most companies continue to be profitable even paying significantly more for hardware / clouds than they potentially can. But it is sad to see nevertheless. Also it increases CO² emissions.

Re: “Clean” code, horrible performance

#666

Post by radicalbyte »

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…

The heuristic is one of those for the mid-experience developer. That's the point where you spend two weeks re-implementing Set to save 1 cycle. Or over abstract. Lots of developers never get past that point.

Experienced devs - such as yourself - generally know how to write reasonably fast code that is also clean (or easy to extend) first time. In my opinion we should be more explicit about this in the heuristics.

Re: “Clean” code, horrible performance

#667

Post by cranium »

You can optimize even further by creating a custom chip to compute the area of shapes in the order of billions per second. But what's the point? Where is the value?

Can't say it better than Knuth:

    We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Clean code has never been about performance, it's about the other people that will read your code – future you included. Performance of people is more valuable for any product than code performance[1]. Only when the performance becomes a bottleneck, or you want to optimize energy efficiency then sure, don't pass that 3% opportunity.

[1] I would argue that it still holds for products that need high(er) performance code like video games, embedded systems, particle physics, ... These products just happen to hit bottlenecks way faster and some have hard cutoffs (eg. 60 fps for a game). Still, not everything needs to be optimized to the extreme: the algorithm to sort an in-game inventory does not need to handle 4B+ items.

Re: “Clean” code, horrible performance

#668

Post by elxr »

bitwize wrote: post #255
bakugo wrote: post #210

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 It's because of this mentality that almost all desktop software nowadays is bloated garbage that needs 2GB of RAM and a 5Ghz CPU to perform even the most basic task that could be done with 1/100th of the resources 20 years ago.

RAM and GPU are cheap. Most users aren't going to notice. Meanwhile by choosing Electron, the developers were able to roll out the app on Windows, Mac, and Linux at nearly zero marginal cost per additional platform.

RAM is not cheap if you look at what apple charges for it.

Re: “Clean” code, horrible performance

#669

Post by DeathArrow »

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…

Casey does not advocate for code optimization. Not writing code in a way that is known to degrade performance does not mean you are doing optimization.

Re: “Clean” code, horrible performance

#670

Post by Olreich »

tyre wrote: post #354
bob1029 wrote: post #241

Earlier quoted context omitted.

> unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board. We should try to steal more ideas from different domains instead of treating them like…

> If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board. Sure but it’s a question of tradeoffs. If the wall-clock-optimized version creates a bus count of 1 for that domain or is difficult for a dozen engineers to iterate on, then that could be worse for the business and users. Should we wan…

Product velocity is not increased by spending a ton of time on complex type hierarchies and premature extensibility. It’s increased by having fewer classes and simpler functions that are faster to write tests for to get good coverage via end-to-end tests. The patterns of OOP increase the amount of time spent not solving the business needs. They also infuse the entire system with unnecessary slowness.
Post reply on HN