3 ms·
On the other hand, software often follows the Pareto principle: 80% of the time is spent executing 20% of the code [^1]. Optimizing/migrating just that 20% wou
by lou1306 9y ago
On the other hand, software often follows the Pareto principle: 80% of the time is spent executing 20% of the code [^1].
Optimizing/migrating just that 20% would yield most of the benefits of a complete rewrite.
(Good luck if that 20% resides in your framework of choice, though).
[^1]: https://www.codeproject.com/Articles/49023/The-impact-of-the-Pareto-principle-in-optimization https://www.codeproject.com/Articles/49023/The-impact-of-the...
- GuB-42 9y agoThe evils of premature optimization are well known but from my experience, execution often isn't the bottleneck, memory is. Which mean you can get a lot of benefits by optimizing your data structures. Making them smaller is a good start. Unfortunately, changing data structures can have far reaching implications, sometimes justifying a complete rewrite. For example, going from string based hashes to raw C structures can yield massive improvements, but you need to rewrite most of the code that access it, even parts that are rarely used. Another performance killer are deep copies. This is also hard to optimize out because if you switch to a more efficient reference, you need to mess up data for the rest of the program in every part that uses it.