读Martin Fowler的Yet Another Optimization Article

Posted 2022-04-30 dingdingfish

那天搜并行的文章时，恰好看到了这篇文章。是2002年的文章，只有2页，但其中一些观点还是有启发的。

1. 首先，性能很重要。一些性能的工作来自于架构设计，一些来自于优化。但仅从设计来看，很难就性能做出判断。 相反，您必须实际运行代码并测量性能。
2. 优化的步骤。首先，您需要一个分析器（Profiler） ：一个可以分析您的程序在其各个部分中花费了多少时间的程序。软件性能也有2/8原则，即80%的时间消耗在20%的代码上。所以首要任务是找到那 20% 的代码。靠经验判断是不准的，此时需要使用到Profiler。然后需要一个自动化测试的工具，同时能够模拟真实的运行条件。
3. 找到瓶颈后，可以有两种选择：加快慢的部分，或减少慢的部分的执行次数。此时就需要改代码。这就是拥有一个设计良好的软件真正有帮助的地方。 优化一个内聚的，松耦合的模块要容易得多。拥有一个好的自动化测试套件可以更容易地发现优化过程中可能出现的错误。
4. 优化一定要多次测量并确认，因优化也可能无效或起反作用。作者引用的Measure twice, cut once，语出自木工，意思是：you should double-check your measurements for accuracy before cutting a piece of wood; otherwise it may be necessary to cut again, wasting time, materials and money. 所有这些都强化了一个关键规则，即首先你需要让你的程序清晰、分解良好和模块化。 只有当你这样做了，你才应该优化。
5. 一些例外：在早期的架构阶段做出的决策在以后要逆转时代价高昂。同样，真正理解这些性能问题的唯一方法是使用测量。此时可以搭建原型系统进行测量，实验仍然比疯狂的猜测要好得多。还有一些大的原则，因为远程调用比进程内调用慢几个数量级，所以尽量减少它们很重要，这会极大地影响整体设计。也就是说，要最小化远程调用。
6. 最后，性能并不是绝对的。 让程序运行得更快需要花钱，是否投资更快的程序是一个商业决策。如果更好的性能可以加速上市时间或带来其它功能，这就表明此时适合进行优化。

如果您进行优化并且不测量以确认性能提高，那么您可以肯定的是，您使代码更难阅读。