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

31–40 of 932 posts

Re: “Clean” code, horrible performance

#31

Post by krona »

lwhi wrote: post #26
vrnvu wrote: post #11

The problem with the contemporary "clean code" concept is that the narrative that performance and efficiency don't matter has been pushed down the throat of all programmers. Re-usability, OOP concepts or pure functional style, design patterns, TDD or XP methodologies are the only things that matter... And if you use them you will write "clean code". Even worse, the more concepts and abstractions you apply to your cod…

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.

Re: “Clean” code, horrible performance

#32

Post by saidinesh5 »

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?

I think the shapes example is more of a dig at various game engines where you end up with a long trees of inheritance (physicsbody -> usercontrollable physics body -> renderable user controllable physics body etc..) as opposed to the recent trend of using something like an Entity Component System.

Also I think he isn't specifically against "clean code" but how the first tool used by various "clean code advocates" seems to be polymorphism via inheritance. I have seen this enough in lots of Java codebases and "Enterprise C++ codebases". "We need X." "Oh first I will create an Abstract Base class for X, then create X, so we can reuse X nicely elsewhere when we need it". It is still on the developers to understand that they may not even need it but for them it is "clean code".

Re: “Clean” code, horrible performance

#33

Post by TheFattestNinja »

vore wrote: post #15

This guy is so dogmatic about it it hurts. I would argue that clean code is a spectrum from how flexible vs how rigid you want your abstractions to be. If your abstractions are too flexible for good performance, dial them back when you see the issue. If your abstractions are too rigid for your software to be extendable, then introduce indirection. We can all write code that glues a very fixed set of things end to end…

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.

Re: “Clean” code, horrible performance

#34

Post by mpweiher »

vrnvu wrote: post #11

The problem with the contemporary "clean code" concept is that the narrative that performance and efficiency don't matter has been pushed down the throat of all programmers. Re-usability, OOP concepts or pure functional style, design patterns, TDD or XP methodologies are the only things that matter... And if you use them you will write "clean code". Even worse, the more concepts and abstractions you apply to your cod…

> TDD or XP methodologies

> the more concepts and abstractions you apply to your code the better programmer you are!

These contradict each other. XP very explicitly opposes introducing (unnecessary) abstractions: YAGNI, DTSTTCPW, etc. And TDD is a good tool for enforcing that, as you only get to write code that you have a failing test case for.

Re: “Clean” code, horrible performance

#35

Post by Arnavion »

10000truths wrote: post #20
Arnavion wrote: post #9

"Use subclasses over enums" must be some niche advice. I've never heard it. The youtuber seems to be referring to some specific example (he refers to specific advice from "them") so I guess there's some context in the other videos of the series. re: the speedup from moving from subclassing to enums - Compiler isn't pulling its weight if it can't devirtualize in such a simple program. re: the speedup from replacing th…

A compiler can only devirtualize a virtual call if it knows the underlying object’s type at compile time, which it certainly won’t for a runtime populated array of base class pointers. CSE doesn’t work across function boundaries unless those functions are inlined, which won’t happen with virtual functions due to the above.

See my reply to anonymoushn's comment.

Re: “Clean” code, horrible performance

#38

Post by suyjuris »

It is also important to consider that better performance also increases your productivity as a developer. For example, you can use simpler algorithms, skip caching, and have faster iteration times. (If your code takes 1min to hit a bug, there are many debugging strategies you cannot use, compared to when it takes 1s. The same is true when you compare 1s and 10ms.)

In the end, it is all tradeoffs. If you have a rough mental model of how code is going to perform, you can make better decisions. Of course, part of this is determining whether it matters for the specific piece of code under consideration. Often it does not.

Re: “Clean” code, horrible performance

#39

Post by lwhi »

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.

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

Re: “Clean” code, horrible performance

#40

Post by zelos »

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?

That does depend on how the abstraction is defined, of course. I once worked on optimising a 2D Canvas C++ class which had a nice top level virtual interface so you could replace it with a different implementation. It was also crazily slow because it defined:

  virtual void setPixel(int x, int y, int color) = 0;
and then implemented flood fill etc in terms of that.
Post reply on HN