“Clean” code, horrible performance • Hacker News Board

Re: “Clean” code, horrible performance

#681

Post by whstl » Wed, Mar 01, 2023, 9:02 AM UTC

simplotek wrote: post #628

xtian wrote: post #528

Earlier quoted context omitted.

So why do 99% of real world applications run like garbage? What’s the culprit?

> So why do 99% of real world applications run like garbage? If you're really interested in the impact of performance issues on everyday life, you need to provide concrete examples instead of putting up unverifiable strawmen. The truth of the matter is that 99% of real world applications run just fine, and it doesn't pay off to invest in shaving milliseconds here or there. Would it be desirable to have a magic wand t…

Since we're talking about React, Facebook's web app is incredibly slow to me, and typing text in some fields is slower than me. As in, it sometimes takes a second for the letters to start showing. And no, it's not a browser rendering issue (even if it were it would be terrible), as disabling JS in Safari brings back the performance.

Another app that I'm not sure if it's React or not is New Reddit. It is significantly slower on my computer and on a lot of people's computer and sometimes you have to refresh the page because it consumes too much memory.

I can come up with other local examples, from Germany. Vatenfall's website seems to "traditional" page navigation, but the content is loaded via a framework. Due to having to reinitialize everything, text takes up to 5 seconds to appear when using the back button or when navigating for page to page. Similar things happen in the German Agentür fur Arbeit.

Re: “Clean” code, horrible performance

#682

Post by hawski » Wed, Mar 01, 2023, 9:08 AM UTC

Cthulhu_ wrote: post #220

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…

An oft recited of thumb: Make it work, make it pretty, make it fast - in that order. That is, performance bottlenecks are easier to find and fix if your code is clean to begin with. I sometimes wish performance was an issue in the projects I work with, but if it is, it's on a higher level / architectural level - things like a point-and-click API gateway performing many separate queries to the SAP server in a loop wit…

I think that I and all non-technical folks around me experience issues with applications performance daily. I think that sometimes "making it work" should include some particular performance metrics. If it is not fast enough it doesn't really work. Now "fast enough" is something to be defined and different depending on the application part.

Far too often I see applications that assume low latency and unbreakable Internet connection. They seem to do almost no caching at all. For example thumbnails.

Also many of applications will be almost unusable (or trigger OOM) when you try to work with a big file. Sometimes a big file has merely tens of MB, sometimes problems start with a 3MB file. Those are the issues that occur without thinking about performance from the start - memory is free, you can copy things around, everything will fit in RAM.

One more thing. When your application consists of a client and a server it may turn out that you will put yourself in a corner when not thinking about performance early on. Everything will work without any troubles at first and then it turns out there are some latency issues with more data and you can't easily upgrade the client for example. Or you had an architecture that allows to spin up more servers and handle the load closer to the client, but it can cut your margins.

Re: “Clean” code, horrible performance

#683

Post by guhcampos » Wed, Mar 01, 2023, 9:13 AM UTC

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 levels of abstraction". We can go further: you won't be going anywhere in computer graphics by trying to "write pure functions" or "avoiding side effects".

These "clean code principles" are, however, rather useful for large, corporate systems, with loads of business process rules maintained by different teams of people, working for multiple third parties with poor job retaining. You don't need to think about vector performance for processing credit card payments. You don't need to think about input latency for batch processing data warehouse jobs, but you need this types of applications to work reliably. Way more reliably than a videogame or a streaming service.

Right tools for the right jobs, people need to stop trying to hammer everything into the same tools. This is not only a bad practice in software, it's a bad practice in life, the search for an ever elusive silver bullet, a panacea, a miracle. Just drop it and get real.

Re: “Clean” code, horrible performance

#684

Post by davydm » Wed, Mar 01, 2023, 9:14 AM UTC

Yay, yet another contrived example to support somebody's position that a process which works fantastically in at least 90% of the time - and yes, I say 90% of the time (as a low-ball) because there _is no perfect process, framework, ideology, _. Everything has compromise. The compromise to make all code chase performance at the cost of maintainability is rubbish as a blanket choice, but may be necessary in certain niche situations.

Re: “Clean” code, horrible performance

#685

Post by whstl » Wed, Mar 01, 2023, 9:16 AM UTC

saagarjha wrote: post #374

jiggawatts wrote: post #322

Earlier quoted context omitted.

Casey makes the point that you don't have to hand-tune assembly code, but instead just write the simpler code . It's easier to write, easier to read, and runs faster too! If there's something wrong with that advice, I can't imagine what it is...

The problem is that Casey has a very particular definition of simple which is problematic to apply in many cases.

Does he? If anything, it is the definition of "Clean Code" that is somewhat special compared to previous usage of OOP and other paradigms.

Casey's definition of simple actually reminds me of the cliché by Rich Hickley. It's simple, but it's not necessarily easy.

Re: “Clean” code, horrible performance

#686

Post by Zvez » Wed, Mar 01, 2023, 9:18 AM UTC

citrin_ru wrote: post #653

yashap wrote: post #263

Earlier quoted context omitted.

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…

Write slow code now, profile and optimize later is how we got all slow software because second step - optimization practically never happens in my experience. Along with the heuristic that hardware and electricity are cheap, developers are expensive. That's probably why managers in my experience almost never ask developers to optimize slow code - they believe it would be cheaper to use more hardware if this fixes the…

>Write slow code now, profile and optimize later is how we got all slow software because second step

We got slow software because we were ok to get slow software. If being fast is not in requirements it means it doesn't matter (for whoever is responsible for defining priorities). Places where performance matters it is never sacrificed.

Re: “Clean” code, horrible performance

#687

Post by strken » Wed, Mar 01, 2023, 9:20 AM UTC

I don't think the tradeoff here is between clean-but-slow code and fast-but-dirty code. It looks more like extensible-but-slow vs fast-but-locked-in. This is pretty obvious - that's why you need the indirection! It's not to satisfy some arbitrary aesthetic principle of cleanliness, it's to make the concept of a shape extensible to anything the calling code wants.

Within one codebase the two behave the same because you can just go rewrite your functions, but if those functions are locked away in someone else's library the "dirty" code flat-out prevents you from ever using more shapes than the library author implemented. Want to add a rhombus? An arbitrary polygon? An ellipsoid? Something defined by Bezier curves for some reason? Well, you just can't; sorry champ.

It's an interesting tradeoff to consider, though. Perhaps we write code like library authors too often, or optimise for extensibility when it isn't needed.

Re: “Clean” code, horrible performance

#688

Post by gjulianm » Wed, Mar 01, 2023, 9:21 AM UTC

fartsucker69 wrote: post #680

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…

There is nothing more maintainable about the clean code variant either.

There is. The first one is that the code with the switch pattern can only process simple shapes. Let's say you want to get the area of a donut now. Well, you need to change the whole code to compute the area of the union. Or imagine that there are other places in the code that need to know the area of a single shape. Do they need to copy/paste the same code?

Re: “Clean” code, horrible performance

#689

Post by cnity » Wed, Mar 01, 2023, 9:22 AM UTC

whstl wrote: post #681

simplotek wrote: post #628

Earlier quoted context omitted.

> So why do 99% of real world applications run like garbage? If you're really interested in the impact of performance issues on everyday life, you need to provide concrete examples instead of putting up unverifiable strawmen. The truth of the matter is that 99% of real world applications run just fine, and it doesn't pay off to invest in shaving milliseconds here or there. Would it be desirable to have a magic wand t…

Since we're talking about React, Facebook's web app is incredibly slow to me, and typing text in some fields is slower than me. As in, it sometimes takes a second for the letters to start showing. And no, it's not a browser rendering issue (even if it were it would be terrible), as disabling JS in Safari brings back the performance. Another app that I'm not sure if it's React or not is New Reddit. It is significantly…

My hot take is that React doesn't directly _cause_ slow performance, but that React is so well marketed as a first place to start for new programmers that the bar for quality is much lower than other industries (like game programming, or even "vanilla JS" which is increasingly seen as an advanced approach).

Re: “Clean” code, horrible performance

#690

Post by incrudible » Wed, Mar 01, 2023, 9:25 AM UTC

cratermoon wrote: post #538

e28eta wrote: post #487

Earlier quoted context omitted.

Author could use a little more memoization in his example, but I suspect that breaks some of the simplicity of his argument. If shape Area is computed often enough that you care about inlining the calculation, why not compute & store it every time the height / width change. That’d be easy enough in an architecture based on information hiding, and might illustrate a legitimate engineering trade-off between those archi…

Right? His Area() function does the calculation from the scratch every call. Either a) make the Shape immutable and calculate area once, at create time, or have the mutator functions recompute the area when they are called. At that point Area() just returns an f32, and the compiler can do all kinds of optimizations.

You are completely changing the problem. Remember, this is an example, the code does the same thing in either implementation.