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

431–440 of 932 posts

Re: “Clean” code, horrible performance

#431

Post by TeMPOraL »

loup-vaillant wrote: post #355
TeMPOraL wrote: post #324

Earlier quoted context omitted.

Casey's implied point is that clean code is already sacrificing performance from the start. And of course real life tells us that those "performance tweaks" will never happen. There is this popular wisdom that security must be designed for from the start, and cannot be just added after the fact. Performance is like that too, except worse, because you actually can add security after the fact - worst-case, you treat th…

> there is no way to sandbox your app so it goes faster. In a number of cases you actually can. Casey demonstrated it in his Refterm lectures, it's caching. You still call the slow thing, but at least you don't call it as often because you have that layer of caching to partially insulate you from its poor performance. Good luck if you have to deal with cache invalidation, though.

Fair enough.

I'll concede on saying that performance and security are alike - you can add some of either after the fact, but you're better off thinking about both from the start.

> Good luck if you have to deal with cache invalidation, though.

Ain't it the truth. Adding a cache is easy. Understanding the implications of doing it is harder.

Re: “Clean” code, horrible performance

#432

Post by naikrovek »

bilvar wrote: post #262
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…

I don't know man, my TV has hardware several orders of magnitude faster and more advanced than the hardware that took us to the moon, and it takes dozens of seconds for apps like Netflix or Amazon Prime Video to load dashboards / change profiles or several seconds to do simple navigation or adjust playback. People just don't know how to properly write software these days, universities just churn out code monkeys with…

yes. I've observed hardware get faster and faster for 30+ years and I've watched software consume all of that headroom the entire time, for no clear reason other than the way we write software is just getting worse and worse and worse.

Re: “Clean” code, horrible performance

#433

Post by whstl »

rileyphone wrote: post #346
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.

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 able to delay complex scaling strategies. Scaling also costs money.

Not to mention that building something with this kind of overhead also means that a lot developer time was spent in the first place, which is still expensive in our industry.

Re: “Clean” code, horrible performance

#434

Post by alfalfasprout »

vore wrote: post #19
anonymoushn wrote: post #17

Earlier quoted context omitted.

Is there any flexbility tradeoff at all here?

The shapes example is pretty contrived so I don't really have an opinion on it either way. But imagine you have something like a File interface and you have implementations of it e.g. DiskFile, NetworkFile, etc., and you anticipate other implementors. Why would you do anything other than have a polymorphic interface?

Right, but the point is you can avoid polymorphism within a given implementation but still keep it at a higher level.

Heck, even codebases used in trading can use polymorphism for very high level interfaces (or async tasks) but hot code paths don't use it.

Re: “Clean” code, horrible performance

#435

Post by jrumbut »

kyralis wrote: post #353
jiggawatts wrote: post #322

Earlier quoted context omitted.

Casey makes the point that you don't have to hand-tune assembly code, but instead just write the simpler code . It's easier to write, easier to read, and runs faster too! If there's something wrong with that advice, I can't imagine what it is...

"Easier to write, easier to read" is the part that's wrong with that advice. It absolutely is, on toy problems like the one described in the article. It very frequently is not when embedded in much larger domains as part of large projects maintained over years by teams.

And when you combine inadequate abstractions with programmers who aren't the kind of geniuses brought in to optimize game engines you get very difficult to fix performance problems.

One of the nice things about some of the clean code concepts he uses is that (as he shows) you can tactically step back from them in key, performance critical areas and reap these wins.

If you stay too low level you get lots of tangled spaghetti code with major performance problems and no obvious way forward besides "make it better."

Re: “Clean” code, horrible performance

#436

Post by loup-vaillant »

maerF0x0 wrote: post #387

If instead of measuring the benchmark of a specific optimized code against a non-optimized code we instead measure the time when the user gets their answer in many cases the non-optimized code will be several months faster. Why? Because it takes time to do optimizations and I can ship the non-optimized sooner. Similarly we can then look at an iterated design and realize the optimized code is frequently going to be ha…

This video is not optimisation. It's about avoiding needlessly slow pasterns that don't even make it more maintainable or cheaper to produce.

Re: “Clean” code, horrible performance

#437

Post by danuker »

dgb23 wrote: post #315
danuker wrote: post #283

Earlier quoted context omitted.

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

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

Re: “Clean” code, horrible performance

#438

Post by jbverschoor »

FridgeSeal wrote: post #294
bitwize wrote: post #255

Earlier quoted context omitted.

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.

> Most users aren't going to notice. And other lies you can tell yourself to sleep at night. Most people notice. Very few have the capacity, power (or realise) to complain about it. They accept what they’ve been given, despite how awful it is, because they have basically no other option. A concrete example: my previous work had to use bitbucket pipelines for our docker builds. My current work uses GitHub actions. GH…

Yup.. and if facebook didn't invest in a native mobile app, they'd been eliminated 10 years ago.

Performance is a feature. Or does anyone here enjoy using an old tomtom gps where every tap on the screen takes 2 seconds? If so, please donate your beefy laptops to charity.

Re: “Clean” code, horrible performance

#439

Post by thenoblesunfish »

quickthrower2 wrote: post #424

Clean code to me is like good writing. It should be easy to read and comprehend later. The rules are not rules but guidelines. I think OO centric rules are harmful in a word where languages support functional programming etc. Polymorphism isn’t always the best answer. A big nested if statement that reads like the business spec can be easier to follow and reason about. That aside if easy to understand code makes your…

And another similarity to good writing - sometimes you really do need to have really dense, precise stuff that isn't easy to understand without a close read. You put that into an appendix when writing, and into optimized low level routines/libraries when writing software. That way you can make things readable, but still have the "performance".

Re: “Clean” code, horrible performance

#440

Post by halayli »

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…

Sounds like someone stuck in their bubble.
Post reply on HN