Re:“Clean” Code, Horrible Performance
by gjulianm on Wednesday March 01, 2023 @04:36AM
(#34980438)
Well, for starters, Amdahl's law exists. If you use design patterns that are 10x slower on a code path that takes only 0.5% of the execution time your application ends up 0.55% slower. And the profiler never tells you how faster can a code path be. It just tells you where are you spending most of your time so you can put the effort where it matters.
[ Parent
| on HN ]
Re:“Clean” Code, Horrible Performance
by trashtester on Wednesday March 01, 2023 @08:28AM
(#34982118)
This is precisely the kind of situation where it's imperative to consider performance before starting to build a new system.
When you hit Amdahl's law, it's because you (or someone else) has made decisions about the high level design/patterns to use in a system. To remove such bottlenecks, you may have to scrap the entire project and start over.
For the inner loops, it's perfectly fine to leave most of the optimization for later. But for overall design, it needs to be right from the start.
Time and time again, I see devs stuck in some paradigm (often front-end devs or low volumen RESTful microservices) that makes it almost impossible to handle non-trival data volumes or traffic, causing new products to fail.
I mean, you always hit Amdahl's law, and the point is that most often the time limits are not that related to the architecture. Let's say you do these "10x slower patterns" in a backend application, in the part where the DB model gets translated to a response to give the client... Yeah, maybe that pattern is slower but most of the time of the response is spent on the network and the DB response.
I do agree that overall design needs to fit performance requirements but for the most part that has nothing to do with "clean code" patterns.