3 ms·
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 applicati
by gjulianm 4y ago
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.
- trashtester 4y agoThis 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.
- gjulianm 4y agoI 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.