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

411–420 of 932 posts

Re: “Clean” code, horrible performance

#411

Post by loup-vaillant »

st3fan wrote: post #149
gjadi wrote: post #131

Earlier quoted context omitted.

I'd say that it really depends on what the code needs to do. For example, if the code is to be distributed and extended as a third-party library, then the class hierarchy is probably a better fit to allow extensibility. But if the purpose of the API is to compute the area of given shapes (as in the example), then it makes sense to make it efficient and there is no use to provide extensibility to the outside world. Th…

> The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. Unfortunately this is just some catchy stereotyping that probably doesn't match reality.

I've seen at least one embodiment of the stereotype 3 months ago. It wasn't pretty, I was able to shrink his code by a factor of 5, and make it more flexible in the process. Among other mistakes he had some idea of flexibility, put part of the infrastructure in place, and then utterly failed to use it, such that when it came to test he required a monkey patching framework for C (Ceedling) so he could mock what he almost already mocked in the source code.

That's a fairly rare breed for sure, but the real problem was that nobody called him out. Well I did, but I'm no longer working there. I couldn't.

Re: “Clean” code, horrible performance

#412

Post by yuliyp »

Turskarama wrote: post #360
heisenbit wrote: post #281

Earlier quoted context omitted.

How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?

Testing, do you not do testing? Use the software. If it seems slow drill down and find the critical path and optimize it.

Testing is often not enough. Developers might have a few test cases with a few records, or a few other users. Real users might do more with it, and things which perform fine in testing suddenly turn into real performance bottlenecks when you're loading an order list with a thousand entries in it instead of two.

Re: “Clean” code, horrible performance

#413

Post by baranoff »

Such a misguided article. What i constantly fight at work is poorly written unmaintainable code. The code that needs to be fast is 1% or less. Use three step rule when implementing something: 1. Make it work 2. Make it pretty 3. Make it fast (measure and optimize where it matters)

Re: “Clean” code, horrible performance

#414

Post by hinkley »

GrumpySloth wrote: post #364

This thread is, predictably, another demonstration of conflating optimisation with being aware of performance. The presented transformation of code away from “clean” code had nothing to do with optimisation. In fact, it made the code more readable IMO. Then it demonstrated that most of those “clean” code commandments are detrimental to performance. So obviously when people saw the word “performance”, they immediately…

>what level of performance is right for your situation will depend on you and your situation

A lot of my performance and code quality chops came from projects where the team was comfortable with the performance of the system but the business was not. They wanted to stop when it was right for them but not right for the situation. It ended up negatively affecting my opinion of them because ultimately I started to see it as deflecting. It's fine because I don't know what else to do, not because this is the best that can be done.

Re: “Clean” code, horrible performance

#415

Post by ajmurmann »

ilyt wrote: post #258
ajmurmann wrote: post #190

Earlier quoted context omitted.

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

Eh, that heavily depends on language and dataset you're working with. I've seen "simple" data with some fat thing like RoR on top of it having 10x the latency of the underlying database after all the ORMing.

Most of my experience with this actually comes from RoR. I worked on one so where rendering slowed everything down to a grind, but more often than not it was making Yu noptimized queries, too many queries, inefficient calls to other services. I used to work as a consultant, so this was true for quite a few apps. However, I also usually was the person most interested in relational databases and my view might have selection bias.

Re: “Clean” code, horrible performance

#416

Post by loup-vaillant »

jstimpfle wrote: post #213
st3fan wrote: post #149

Earlier quoted context omitted.

> The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. Unfortunately this is just some catchy stereotyping that probably doesn't match reality.

The code examples with the abstract / virtual methods for the most straightforward concepts are a clown show. Not cleanliness but madness.

That's what you get with SOLID. Madness.

Re: “Clean” code, horrible performance

#417

Post by TeMPOraL »

saagarjha wrote: post #396
TeMPOraL wrote: post #348

Earlier quoted context omitted.

Except when it isn't. I remember an article making rounds the other day, that claimed the whole "most software spend most time waiting on I/O" common wisdom is no longer true, as most software these days is CPU-bound, and a good chunk of that is parsing JSON.

For pure compute most software is memory bandwidth bound and for large applications I/O is generally still a problem given the costs of flash.

> For pure compute most software is memory bandwidth bound

This is related, though. While the final leaps of performance often come from using more memory to make CPU work less, in my experience, most of the performance-problematic code wastes both CPU and memory, and meaningfully faster alternatives end up using less of both.

Either way, from the end-user perspective, I tentatively agree with the article I mentioned (but don't have a link handy, sorry) - most of the software I end up using, or see people around me using, is clearly CPU-bound, briefly network I/O-bound (mostly web apps), and rarely local I/O-bound.

EDIT: I guess the caveat is that end-user software is often spending 99% time doing nothing at all, just waiting for user input. But that bit doesn't matter - what matters is how fast it reacts to the input once the user starts providing it. This is where a lot of software suddenly gets CPU-bound (or net IO-bound, if doing something stupid).

Re: “Clean” code, horrible performance

#419

Post by gardenhedge »

fvdessen wrote: post #272
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 once optimised a SPA app that had to be really fast for usability reasons (industrial use), I replaced all the 'high level' JS patterns such as map, filter, and frontend framework things to use just if else and for loops and native dom manipulation, and it ended up more than 10x faster, each click would update the app in one frame, it was very noticeable. So yes CPU cycles do matter for websites, even with modern h…

I'd be interested in a blog post on this. Why is JS map so much slower than a for loop?

Re: “Clean” code, horrible performance

#420

Post by naikrovek »

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 think the author is taking general advice and applying it to a niche situation.

I don't. how many programs are running in your OS right now? how much CPU do you need to keep those things plus the things you need running in a performant manner?

how much CPU would you need if things performed better? the answer is "less" every time.

better software performance = less money required for hardware to obtain the responsiveness you require.

it's important, and it's important completely independently of how it is framed here.

just wait till you've seen software get slower for 30 years. to put it another way, watch hardware get faster and faster and faster for 30 years while you observe software continually consume all of the available headroom until it feels slow again. watch that happen for THREE DECADES and wait for someone to tell you that everything is fine and that someone saying "software is unnecessarily slow" is wrong because they aren't framing their argument how you think it should be framed.

Post reply on HN