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

111–120 of 932 posts

Re: “Clean” code, horrible performance

#111

Post by TheFattestNinja »

st3fan wrote: post #91
TheFattestNinja wrote: post #33

Earlier quoted context omitted.

Casey is a bit of a hardcore crusader on the topic, but I'd hardly call dogmatic someone who can provide you evidence and measurements backing their thesis. The tests he put together here are hardly something I'd call a straw-man argument, they seem like reasonable simplification of real-cases.

Evidence in a micro benchmark of a single page of code. The focus on performance here ignores the fact that most programs are large systems of many things that interact with each other. That is where good design and abstractions and “clean code” can really help. Like all things it is about finding a balance and applying the right techniques to the right parts of a larger system.

True, the example is simplistic, but that's just to make it fit within reasonable exposition. The author has in the past shown (elsewhere) how his techniques can actually make dramatic differences in more concrete examples (he rose to some Internet fame for building a performant shell that could actually handle larger outputs orders of magnitude better than most available alternatives).

To me the interesting point is the reminder that there is an innate tension between going fast and being "clean" (i.e. maintanable/understandable). And once you are aware of it you can make your decisions in an informed way. Too often this tension is forgotten/ignored/dogmatically put to the back ("performance doesn't matter over cleanliness" and the likes).

Mind you, I'm also of the camp that performance is very secondary to cleanliness in modern enterprises, but I appreciate a reminder of just how much we are sacrificing on this altar.

Re: “Clean” code, horrible performance

#112

Post by hennell »

anonymoushn wrote: post #16
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…

If someone is new to the codebase, would you rather they need to open a dozen files to see all of the different virtual functions that could occur at one call site, or open one file?

As tradeoffs go, I don't see opening a dozen files as a big hurdle. I'd take smaller single purpose files over one big file anyday.

Plus how often do you need to see all functions? If there's a problem in RectangleArea function, you go to that file, no need to look in CircleArea. If you're adding 'StarShapeArea' you only care that it matches the callers expectations, not worrying about the other function logic.

Re: “Clean” code, horrible performance

#113

Post by gjadi »

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…

I didn't watch the video but I read the article and in the later part he shows how to extend every versions (polymorphic, enum and table-based) to "computing the sum of the corner-weighted areas".

This extension is easy enough with in the non-pessimistic case (table based).

Re: “Clean” code, horrible performance

#114

Post by Ygg2 »

krona wrote: post #31
lwhi wrote: post #26

Earlier quoted context omitted.

If you have more than one person working on a codebase; clean code matters a lot. A code base that can't be understood and maintained by the whole team, will degrade quickly.

Nobody is saying maintainable code isn't important but rather that clean vs fast is a false dichotomy.

There are competeing in my opinion. Many techniques to make code fast will make it less readable.

Techniques like manual code unrolling/inlining, writing branchless code, compressing data to fit into a pointer, etc.

Re: “Clean” code, horrible performance

#115

Post by TeMPOraL »

tizzy wrote: post #53
js6i wrote: post #10

Earlier quoted context omitted.

Huh? Coffee shops optimize for people not bumping into each other and having related items close together, and don't pretend to not know what kind of gear they have.. that's not a terrible analogy to the exact opposite argument.

I think the sentiment is that order and organisation is helpful in achieving goals and cultivating a good working environment as opposed to a big mess. Analogies, just like abstractions, are leaky.

Yeah, but this one leaks a smart-matter paint that self-assembles into a shape of text saying "the order and organization is not the goal, but a consequence of ruthlessly optimizing for performance above all".

Re: “Clean” code, horrible performance

#116

Post by Tomis02 »

xnickb wrote: post #41
anonymoushn wrote: post #16

Earlier quoted context omitted.

If someone is new to the codebase, would you rather they need to open a dozen files to see all of the different virtual functions that could occur at one call site, or open one file?

I see your point, but no one uses Windows notepad for coding anymore. There are far worse crimes than having code structure that spans several files.

> There are far worse crimes than having code structure that spans several files.

Sure, but what's the advantage of having your code split over several files? Yes, you can jump between them with an IDE, but that's still a disruption, and it makes it harder to see common patterns that can help you simplify the code.

As demonstrated in the video, splitting up the switch into multiple classes only hurts readability.

Re: “Clean” code, horrible performance

#117

Post by TeMPOraL »

xnickb wrote: post #41
anonymoushn wrote: post #16

Earlier quoted context omitted.

If someone is new to the codebase, would you rather they need to open a dozen files to see all of the different virtual functions that could occur at one call site, or open one file?

I see your point, but no one uses Windows notepad for coding anymore. There are far worse crimes than having code structure that spans several files.

> I see your point, but no one uses Windows notepad for coding anymore.

Did I miss an IDE that inlines all those things for you automatically? Because ones that only give you a "jump to definition", or maybe a one-at-a-time preview in a context popup, are not much better than Notepad++. You still don't get to see all the relevant things at the same time.

Re: “Clean” code, horrible performance

#118

Post by Jach »

captainmuon wrote: post #93

Already in his first example, where he says he doesn't use range-based for in order to help the compiler and get a charitable result, he doesn't get the point, I think. You write code in a certain way in order to be able to use abstractions like range-based for, or functional style. If you are hand-unrolling the loop, or using a switch statement instead of polymorphism, you loose the ability to use that abstraction.…

Perhaps some biases can be excused by committing to C++. Using dynamic dispatch in that language seems to be slow when it's pretty much always some vtable lookups under the hood, but it doesn't have to be that way. Implementations of other languages like Smalltalk or Common Lisp automatically apply (or have as options to specify) various strategies to make convenient abstractions a lot more performant. In Java Land the JVM can do many impressive things -- and interestingly, more numbers of smaller size methods helps, as it tends to "give up" if a function is a giant sprawling mess.

A fun story from https://snakeisland.com/aplhiperf.pdf on the utility of people using standard inner product / matrix multiplication operators, instead of hard-coding their own loops or whatever:

> In the late 1970’s, I was manager of the APL development department at I.P. Sharp Associates Limited. A number of users of our system were concerned about the performance of the ∨.∧ inner product on large Boolean arrays in graph computations. I realized that a permuted loop order would permit vectorization of the Boolean calculations, even on a non-vector machine. David Allen implemented the algorithm and obtained a thousand-fold speedup factor on the problem. This made all Boolean matrix products immediately practical in APL, and our user (and many others) went away very happy.

> What made things even better was that the work had benefit for all inner products, not just the Boolean ones. The standard +.× now ran 2.5—3 times faster than Fortran. The cost of inner products which required type conversion of the left argument ran considerably faster, because those elements were only fetched once, rather than N times. All array accesses were now stride one, which improved cache hit ratios, and so on. So, rather than merely speeding up one library subroutine, we sped up a whole family of hundreds of such routines (even those that had never been used yet!), with no more effort than would have been required for one.

Or, just look at SQL. I sure appreciate not having to write explicit loops querying the correct indexes every time I want to access some data.

Re: “Clean” code, horrible performance

#119

Post by TeMPOraL »

oleg_antonyan wrote: post #79
theknarf wrote: post #55

This seems more like an argument against the object oriented model of C++ than anything else. Would have been more interesting if the performance was compared to languages like Rust.

Indeed. If anything this demo shows how badly C++ polymorphism performs. It doesn't necessarly means that all OOP languages created equal. Although I have no data to prove anything, and frankly don't care b/c all these arguments about clean vs dirty code are meaningless in an absence of formally defined rules and metrics universally enforced by some authority that can revoke your sw dev license or something like that

> It doesn't necessarly means that all OOP languages created equal.

Exactly - unless you're trying very hard, you're unlikely to beat C++ polymorphism with your OOP code in a different language. Which makes Casey's argument that much stronger. C++ with its relatively unsophisticated OOP and minimal overhead on everything, is as fast as you're going to get, so it's good for showing just how slow that still is if you follow the Uncle Bob et al. Clean Code tradition.

Re: “Clean” code, horrible performance

#120

Post by Ygg2 »

gjadi wrote: post #59
lwhi wrote: post #39

Earlier quoted context omitted.

Okay, so we should aim for clean AND fast code?

One can argue that simple code is both fast and clean. However, you can only measure how fast (or slow) your code is, so make it simple, aim for fast and hope it's clean (:

One can argue that extremes of fast and clean code will both result in something horrific.

What Casey is doing is showing how bad a hammer is at removing screws. I mean duh, you're removing screws with a hammer.

Post reply on HN