当优化不再是“微优化”时

Question

我是一名团队领导/功能架构师，从开发人员的角度出发，所以我拥有编码经验，而且我现在已经开发了很多东西。现在到了这一点：为了重构（以及一些怀旧）而回顾一些代码我发现了一堆可以优化的地方，所以作为一个练习我给自己2天时间来探索和改进很多东西。运行基准测试后，我发现一般模块性能提高了约5％。

所以我接受了一些同事（以及我所经营的团队）并提出了我的更改。我对“微优化”的总体印象感到惊讶。如果你看看每一个优化，那么是的，它们是微观的，但如果你看一下大局......

所以我的问题是：何时优化不再被视为“微观”？

Answer 1

优化是否为微观通常并不重要。重要的是它是否能给你带来任何好处。

你写道，你花了两个整个工作日来提高5％的性能。你明智地度过了那些日子吗？那些东西是你修复了应用程序中“最慢”的部分，还是至少那些最容易解决性能问题的东西？您的更改是否达到了您的性能目标（之前您没有做过）？在您的情况下，5％的性能是否重要？如果您发现需要提高性能，通常需要增加100％或1000％。

您是否可以在不影响代码的可读性和/或可维护性的情况下执行优化？

此外，这些优化带来了哪些其他成本？您需要执行多少回归测试？你创造了多少新bug？

我知道，这看起来更像问题而不是答案，但这些问题应该决定您做出优化的决定。

Answer 2

就个人而言，我会区分导致算法时间或空间复杂度降低的变化（例如，从O(N^2)到O(N)）以及加速代码或降低内存要求的更改但要保持整体的复杂性。我称之为后者的微观优化。

但是，请记住，虽然这是一个精确的定义，但它不应该是决定变更是否值得保留的唯一标准：降低代码复杂性（如难以理解）通常更为重要，特别是如果速度和记忆要求不是引起关注的主要原因。

最终，答案将取决于您的项目：对于在嵌入式设备上运行的软件，规则与在Hadoop集群上运行的内容不同。