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

271–280 of 932 posts

Re: “Clean” code, horrible performance

#271

Post by kaba0 »

morelisp wrote: post #248
kaba0 wrote: post #166

Earlier quoted context omitted.

One can reasonably well guess/know the expected input sizes to their programs. You ain’t (hopefully) loading your whole database into memory, and unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop, that’s just not how most programs look like. If it is, then you should design for it, which may even mean changing programmi…

> You ain’t (hopefully) loading your whole database into memory I've basically built my career for the past decade by pointing out "yes, we can load our whole working set into memory" for the vast majority of problems. This is especially true if you have so little data you think you don't have CPU problems either.

Databases are often not used by a single entity, so while I am very interested in your experiences, I think it is a great specialization for certain problems, but is not a general solution to everything.

All in all, I fail to see how it disagrees with my points.

Re: “Clean” code, horrible performance

#272

Post by fvdessen »

PragmaticPulp wrote: post #216
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 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 hardware. However the code was more verbose and needed a lot more technical know-how to understand and maintain.

Re: “Clean” code, horrible performance

#273

Post by commandlinefan »

boredumb wrote: post #204

I've seen clean code lead to over-architected and unmaintainable nightmares that ended up with incorrect abstractions that became much more of a problem than performance. The more the years pile up the more I agree with the sentiment in this post, generally going for something that works and is as optimal of code as I would get if I was to come back to make it more performance oriented in the future, I end up with so…

> I've seen clean code lead to over-architected and unmaintainable nightmares

I agree, but surely you wouldn't really say that his end-state in this particular article is more maintainable than the starting point.

Re: “Clean” code, horrible performance

#274

Post by scotty79 »

stunpix wrote: post #150

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere "? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method…

> "we have 20x loss in performance everywhere"?

I guess only in the places you call methods?

Wait? Are they everywhere? Hmmm...

Re: “Clean” code, horrible performance

#275

Post by Johanx64 »

hennell wrote: post #13

I think he's really underplaying the main selling point of clean code - the objective of writing clear maintainable, extendable code. His code was faster, but sometimes how it compares for adding new features or fixing bugs by people new to a code base is where you want to optimize. Should performance be talked about more? Yes. Does this show valuable performance benifits? Also yes. Is performance where you want to s…

> Main selling point of clean code - the objective of writing clear maintainable, extendable code

That's the alleged selling point, whether even that's true is arguable.

Since while performance can be clearly measured - whether the given "clear code" principles do in fact help with writing "maintainable and extendable code" is something that can be argued back and forth for a long time.

Re: “Clean” code, horrible performance

#276

Post by kps »

pkolaczk wrote: post #82

Most of those Clean code rules are BS. 1. Prefer polymorphism to “if/else” and “switch” - if anything, that makes code less readable, as it hides the dispatch targets. Switch/if is much more direct and explicit. And traditional OOP polymorphism like in C++ or Java makes the code extensible in one particular dimension (types) at the expense of making it non-extensible in another dimension (operations), so there is no…

> Prefer polymorphism to “if/else” and “switch” - if anything, that makes code less readable, as it hides the dispatch targets.

Worse, I think, is that it hides the condition, which can be arbitrarily far away in space and time.

Certainly dynamic dispatch can be very useful, and the abstraction can be clearer than the alternatives. A rule of thumb is to consider whether you'd do it if you were writing in C, using explicit tables of function pointers. If that would be clearer than conditional statements, do it.

(In case it isn't obvious, I'm talking about languages in the C++/Java vein here.)

Re: “Clean” code, horrible performance

#277

Post by gary_0 »

PragmaticPulp wrote: post #216
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 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.

Re: “Clean” code, horrible performance

#278

Post by WatchDog »

mquander wrote: post #196
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. 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…

Most of these websites have neither clean code nor hyper optimisation, just bad code all round.

Re: “Clean” code, horrible performance

#279

Post by hbrn »

sebstefan wrote: post #100
pkolaczk wrote: post #82

Most of those Clean code rules are BS. 1. Prefer polymorphism to “if/else” and “switch” - if anything, that makes code less readable, as it hides the dispatch targets. Switch/if is much more direct and explicit. And traditional OOP polymorphism like in C++ or Java makes the code extensible in one particular dimension (types) at the expense of making it non-extensible in another dimension (operations), so there is no…

In his small example he already added unforeseen couplings that could get out of hands if it was a big codebase. If you follow the principle "switch statements over [X]", try to add a new shape down the line and see how quickly you run into problems. In the clean code version, your compiler will remind you to implement calculateArea, calculateNumberOfVertices, calculateWhatever, and so on and so forth. With his versi…

> he already added unforeseen couplings that could get out of hands if it was a big codebase

And one should be able to fix things that get out of hand when they start getting out of hand. Architecture should be based on current facts, not on our fantasies about the future.

For some reason we're always making this weird assumption that future engineers working on a problem are going to be less capable than us. So we decouple things in advance for them. Those future idiots won't know how to architect for scale, but we, today, with our limited domain expertise, know better.

The reality is that in most cases we are those future engineers. And, unsurprisingly, "future we" tend to know more, not less.

Post reply on HN