我是一名从开发人员职位上脱颖而出的团队负责人/功能架构师，所以我有编码经验，而且现在正在发展的许多事情都是由我首先实现的。现在到重点：为了重构（和一些怀旧）而审查一些代码 我发现了很多可以优化的地方，所以作为一个练习，我给了自己 2 天的时间来探索和改进很多东西。运行基准测试后，我发现总体模块性能提高了约 5%。
因此，我联系了一些同事（以及我管理的团队）并介绍了我的更改。我对“微优化”的一般印象感到惊讶。如果您确实查看每一个优化，那么是的，它们是微观的，但是如果您看大局......
所以我的问题是：什么时候优化不再被视为“微”？
优化是否是微观的通常并不重要。重要的是它是否能让你物有所值。
你写道，你花了整整两个工作日来提高 5% 的性能。你是否明智地度过了那些日子？您修复了应用程序中“最慢”的部分，或者至少是那些最容易修复的性能问题？您的更改是否使您达到了绩效目标（您以前没有这样做过）？在您的情况下，5% 的性能是否重要？通常，如果您发现需要提高绩效，您会希望提高 100% 或 1000%。
您能否在不影响代码的可读性和/或可维护性的情况下执行优化？
此外，这些优化还带来了哪些其他成本？您需要执行多少回归测试？你创造了多少新的错误？
我知道，这看起来更像是问题而不是答案，但这些问题应该决定您是否做出优化的决定。
就个人而言，我会区分导致算法时间或空间复杂度降低的更改（例如从O(N^2)到O(N)）和加速代码或减少其内存需求但保持整体复杂性相同的更改。我称后者为微优化。
但是，请记住，虽然这是一个精确的定义，但它不应该是决定是否值得保留更改的唯一标准：降低代码复杂性（如难以理解）通常更重要，尤其是在速度和内存要求不高的情况下不是引起关注的主要原因。
最终，答案将取决于您的项目：对于在嵌入式设备上运行的软件，规则与在 Hadoop 集群上运行的东西不同。