3 ms·
As a general rule, optimize for your bottlenecks. If you have a large sum of I/O and can see the latency tracked and which parts of the code are problematic, o
by ysavir 4y ago
As a general rule, optimize for your bottlenecks.
If you have a large sum of I/O and can see the latency tracked and which parts of the code are problematic, optimize those parts for execution speed.
If you have frequent code changes with an evolving product, and I/O that doesn't raise concerns, then optimize for code cleanliness.
Never reach for a solution before you understand the problem. Once you understand the problem, you won't have to search for a solution; the solution will be right in front of you.
Don't put too much stock in articles or arguments that stress solutions to imaginary problems. They aren't meant to help you. Appreciate any decent take-aways you can, make the most of them, but when it comes to your own implementations, start by understanding your own problems, and not any rules, blog titles, or dogmas you've previously come across.
- rolldat777 4y agoI think this is the point. In the example given, if you introduce a sqrt, then the argument becomes much weaker already. The dispatch is comparable to the computation time. I'm reminded of "Latency Numbers Every Programmer Should Know". I actually just had this debate with myself, specifically about shape classes including circles and bezier curves. However, the operation was instead intersections. There was zero performance difference in that case after profiling so I kept the OOP so that the code wasn't full of case statements.
- _dain_ 4y agoIt's a shifting target though. Let's take your example of a program with a lot of I/O. A straightforward way to optimize that is to find a way to reduce the number of I/O operations you do. And once you do that, the bottleneck shifts. You're spending less time in I/O, both in an absolute sense and relative sense. So you might run into a new non-I/O new bottleneck that was just drowned out in the noise before. So you optimize that ... And sometimes this goes on for many iteration cycles and you end up with a 100-1000x performance improvement.