Performance 当优化不再是；“微观优化”；

我是一名从开发人员的职位上脱颖而出的团队负责人/特性架构师，因此我有编码经验，现在很多东西都是由我首先实现的。现在我要说的是：为了重构（和一些怀旧）而回顾一些代码，我发现了很多可以优化的地方，所以作为一个练习，我给自己两天时间来探索和改进很多东西。运行基准测试后，我发现通用模块的性能提高了约5%

因此，我询问了一些同事（以及我管理的团队）并介绍了我的变化。我对“微观优化”的总体印象感到惊讶。如果你看每一个优化，那么是的，它们是微观的，但如果你看大局

---

所以我的问题是：什么时候优化不再被认为是“微观的”

我个人会区分导致算法时间或空间复杂性降低的变化（例如从

O（N^2）

到

O（N）

）以及加快代码速度或减少内存需求但保持总体复杂性不变的更改。我将后者称为微观优化

但是，请记住，虽然这是一个精确的定义，但它不应该是决定更改是否值得保留的唯一标准：降低代码复杂性（如难以理解）通常更为重要，特别是在速度和内存需求不是主要问题的情况下

---

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

优化是否是微型的通常并不重要。重要的是它是否能让你赚大钱

你写道，你花了整整两个工作日来提高5%的绩效。你是否明智地度过了那些日子？您修复的是应用程序中“最慢”的部分，还是最容易修复的性能问题？你的改变是否使你达到了你的绩效目标（你以前没有做到）？在您的情况下，5%的性能是否重要？如果你发现自己需要提高绩效，通常你会想要100%或1000%的加薪

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

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

---

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

问“我是否可以通过优化程序架构获得更高的性能？”是否有意义？只是一个想法……这将是一个长时间的讨论（所以可能不适合这样做）但首先，做一个领导者……通过做你的团队工作，你不是在领导他们，你最好让团队列出一个他们希望重构的事情的列表，让他们优先考虑这个列表（在那里你可以有发言权），然后你管理这个列表来解决问题。当优化不再有效时“微观优化”当它在现实世界中产生可测量的性能优势时。几乎是故事的结尾。5%的性能改进意味着什么？一些操作花费的时间减少了5%？执行优化的代码路径的基准快了5%？或者整个代码程序的实际基准快了5%？在任何情况下，5%似乎无关紧要（虽然它在某些情况下可能有用）。我认为在很多情况下，一个被广泛认为是“微型”的单一优化可能会产生这样的效果（在优化应用的范围内，即优化）。@meagar我不知道其他人，但这不是我使用的术语。优化内存布局以提高缓存利用率（例如，使用数组而不是链表，即使只需要顺序访问）很容易产生重大影响，但我仍然将其视为一种微观优化。这更多的是关于应用更改的级别，而不是影响。