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

901–910 of 932 posts

Re: “Clean” code, horrible performance

#901

Post by loup-vaillant »

berkes wrote: post #891
loup-vaillant wrote: post #871

Earlier quoted context omitted.

Bob Martin should back his claims up. He asserted many things in his book, without evidence, and with examples so bad most of them actually hurt his case. "Clean Code" is just a bad book, best ignored. Great speaker, though. --- As for SOLID, there's one good thing: Barbara Liskov. Her principle have mathematical underpinnings in type theory, shapes Haskell's type classes and likely Rust traits too. The rest however…

Still sounds like your opinion vs his. That's not "failing" that's at most "it doesn't work for me", but without explaining why it doesn't work for you, it really is little more than a wild claim. I've had great success with "Clean code" practices. Though I implement it more according to Alistair Cockburns' "Hexagonal Architecture", it's overall very similar and strives for the same goals using the same methods. So i…

> Still sound like your opinion vs his.

Can't do much better in short HN comments. I've tried at times to be more rigorous than that, but so far I've only scratched the surface: https://loup-vaillant.fr/articles/good-code

Re: “Clean” code, horrible performance

#902

Post by whstl »

scotty79 wrote: post #721
guhcampos wrote: post #683

I don't like most of these "principles", as anyone can verify by looking at my previous comments, but this article is cherry-picking to its utmost level of unfairness. These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics. I've never seen anyone seriously try to write computer graphics while "keeping functions small" and "not mixing le…

Yeah, but why is good and fast opposite rather than orthogonal? Why languages and compilers are not built so at least we can do both. Or even better, why is good and fast not the same thing in computer languages?

Good point.

But I'd point that languages and compilers are built so we can have both.

The problem is some definitions of good really aren't, and it isn't just because they're slow, it's because they make some things "good" at the detriment of others. Uncle Bob's Clean Code is really good at making some portions of the code "good" and "simple", but when put together they are interconnected in ways that are more difficult to understand.

Re: “Clean” code, horrible performance

#903

Post by zamalek »

DeathArrow wrote: post #656
zamalek wrote: post #596

Earlier quoted context omitted.

Exactly. The problems of software performance come from decades of poorly/quickly executed evolutionary change resulting in bad systems design. It's all an new abstraction over an older abstraction over an even older abstraction, because some old application still needs to be supported (something Casey has likely never had the problem of worrying about in game development). Game developers have the luxury of starting…

I am a developer who worked on embedded, desktop apps, mobile apps, games and now on large microservice based application. A developer is a developer and can move from one kind of application to another. I find what Casey says in his videos to be true. And I though about that stuff before I even watched his videos, which are excellent. However, I started not to care. I don't want to start fights inside the company, e…

> I just hope that the industry as a whole will wake up from the whole OOP nightmare.

I agree with that 100%. OOP is a giant mess, no matter where your stance on code clarity or performance stands. It's objectively worse in both regards.

Re: “Clean” code, horrible performance

#904

Post by mtrower »

fer wrote: post #849
_dain_ wrote: post #802

Earlier quoted context omitted.

>Just toss a 0.01ms I/O operation in those loops; it will throw the numbers off by a large margin, then one would just rather pick sanity over the speed gains without blinking. I mean, yes, if you do something completely fucking idiotic like put an IO operation inside a tight calculation loop, then all your speed gains will vanish. But I don't see how that refutes anything.

I said I/O, but it could be memory access. All he does fits in registers and maybe cache. Also, 0.01ms was the normal RAM latency when I started using computers... Do you remember the last time you had to do a tight calculation loop, and not only that, but one that significantly impacted the total runtime? Personally I do, it was roughly 15 years ago writing a raytracer. I can imagine that happening in game/3D dev, D…

> All he does fits in registers and maybe cache.

Well yes, that's.. actually the point. Indirectly, anyway anyway.

> I mean, Python is slow as an old dog, yet it gets most of the ML fun.

Python driving some UI and logic, with a ton of optimized Fortran and C driving everything hot.

Re: “Clean” code, horrible performance

#905

Post by gofreddygo »

yashap wrote: post #263
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…

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

Some more indirect reasons

- shit UX "ideas" that trigger 10 new API calls to show dialogs and popups.

- Logging libs under pressure

- overemphasis on testability

Re: “Clean” code, horrible performance

#906

Post by mtrower »

unconed wrote: post #892
Olreich wrote: post #107

Earlier quoted context omitted.

To summarize: if you make the problem complex enough, then the specific performance methods used in the article don’t work. But hey, why not take your complex example? If you apply a polymorphic approach to Bézier curves and polygons, then you still get a 1.5x slowdown compared to a switch statement. If you have any commonality between your implementations of area for them, it’s harder to find, which could be worth 2…

Being able to handle arbitrarily polygons isn't insane complexity, it's actually the minimum viable complexity needed to handle any basic shape a user might want to use. Limiting them to a handful of precomputed ones is the kind of limitation only a software developer can live with and love. And once you can handle arbitrary polygons, writing and maintaining special case code has to be justified with evidence that yo…

If your area of expertise is putting out a general purpose shape area compute library, then maybe. If your purpose is elsewhere and this code is a tool to accomplish that --- not so much. Not everything needs to be fully general. Write the tool you need, whatever that ends up being.

Re: “Clean” code, horrible performance

#908

Post by randomdata »

hinkley wrote: post #819
sethammons wrote: post #727

Earlier quoted context omitted.

You seem to ignore that when the unit changes, the tests do too. If you come back a year later, foo.bar.baz(quux) might have been refactored and lazily so. The tests were also updated and still pass. You may jump into the code only to realize that someone no-op'd everything and never removed call sites. TDD is primarily a design tool, not a lock-into-implementation tool.

Someone has put some notion of function identity in his head and I don’t know what school taught that notion but it needs to burn. IBM’s Visual Age tried to behave that way and it didn’t end well. Eclipse dropped that conceit when it forked.

> Someone has put some notion of function identity in his head

The only comment that talks about function identity is this one[1], and it is written by you. "His head" refers to your own?

I used the word identity earlier in that thread, but I definitely wasn't referring to functions. The word "function" isn't even found in the comment.

[1] https://news.ycombinator.com/item?id=34983709

Re: “Clean” code, horrible performance

#909

Post by mtrower »

KyeRussell wrote: post #132
drainyard wrote: post #50

Earlier quoted context omitted.

It seems like you may be assuming that Casey is arguing against writing clear code, which he is not. He is arguing that you should just write the simple thing and usually that is also the most clear, readable and "maintainable" code because it is easy to get an overview of. So what he is arguing for does not fit your coffee shop example, because of course no one should write unreadable code. The argument is that some…

This advice doesn’t really differ from the actual ‘source material’ though. It’s really arguing against the people that learned what “clean code” is from a blog post or a Tweet or (most likely of all) another YouTuber that tried to take a complex engineering topic that they don’t have the experience to understand, and shove it into a video-listicle full of DigitalOcean ads and forced facial expressions. You see the s…

> people that learned what “clean code” is from a blog post or a Tweet or (most likely of all) another YouTuber

Or, you know, college. Though I can only speak of my local tech college, not full blown university. I don't bear them any ill will --- there's a hell of a lot to try to teach in two years --- but a lot of the things that were taught in my degree, were very dogmatic.

Re: “Clean” code, horrible performance

#910

Post by mtrower »

Tomis02 wrote: post #590
rudolph9 wrote: post #335

> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3% https://dl.acm.org/doi/10.1145/356635.356640 The author of the post fails to articulate how we strike a healthy balance and instead comes up with contrived examples to prove points that only really apply to contrived examples.

You managed to misunderstand both Casey Muratori and Donald Knuth. You are not alone, the majority of the industry seems to have gotten it wrong. Casey tells you that following "Clean Code" can give you a huge performance hit for no obvious benefit. And even if "Clean Code" were to be more maintainable (it's not; in my experience, it's actually worse for maintainability), you should still be extremely aware of the co…

Also worth noting what his idea of a "small efficiency" was; he goes on to note that, say, 12% efficiency, easily gained, is not small at all!

He never says to throw all ideas of performance out the window when writing your initial run of code. It's just not worth it to dig down into the weeds and micro-optimize everything ahead of time, is all.

But people just take this quote as liberty to completely ignore all notion of performance in their code. Maddening, and a total disservice to Knuth.

Post reply on HN