各种早期优化的特点/类型是什么？

Question

对于代码审查技术培训，我必须涵盖各种主题。其中之一是过早优化。我发现它有三个特点：

1. 它通常是邪恶的，会产生相反的效果。
2. 这是一种不必要的痛苦，不会带来任何好处。
3. 它需要付出很大的努力才能获得很少的好处。

还有什么我遗漏的特质吗？另外，为了说明它们，我通常只得到第一个场景的一个好例子。有人能为第二和第三种情况提出任何可靠的例子吗？

例如，第一种情况：

用char代替int用于更小的循环以节省字节！

for(char c = 0; c < 20; c++) {} //Evil: Accessing 'char' costlier than 'int'

注意:我并不担心编译器本身通常会处理一些不成熟的东西。这种培训只是为了说明。

这个问题不是关于"什么优化是不成熟的？“

Answer 1

过早优化：

1. 是基于未经测量的假设性能，以及
2. 被用作拙劣的应用程序设计的借口。

第一点说，性能优化应该基于配置代码，这样您就可以集中精力在热点上，并得到最大的回报。

第二点说，你不应该仅仅因为你认为所有的优化都太早就抛弃它们。所谓的过早优化的“邪恶”并不是在应用程序完成之前完全忽略性能的借口。如果您这样做，您可能会发现您的设计没有规模，您将不得不重写它的很大一部分。

为您的程序选择适当的数据结构是早期性能优化的一个例子，这不仅是可取的，而且是必要的。好的设计永远不会过早。

Answer 2

过早的优化往往是：

• 微观优化。在最低层次上进行优化。以设计为代价，专注于(不相关的)实现细节。例如优化内环，而不是设计没有循环的算法。
• 在代码工作之前完成，因此打破了：让它发挥作用。把它做好。快一点。的黄金规则
• 到处都是琐碎的特殊情况
• 不必要地添加实体或概念，从而违反Occam的剃刀

Answer 3

最重要的是，优化常常使代码的可读性大大降低。在不需要优化的情况下进行优化肯定是不成熟的。只有在代码完成并且需要优化时，才应该进行优化。作为经验法则，作者应该能够激发为什么有必要进行某种优化，并在源代码注释中这样做。

在最不成熟的优化中，您会发现类似于函数的宏、文件作用域变量只是为了速度而声明的、特殊的模糊循环(倒计时就是一个例子)、将所有代码移动到h文件以便可以内联等等。

当然，除非优化不会降低代码的可读性。其中一个例子是通过引用而不是通过值传递结构/对象。这种优化不会降低代码的可读性，因为它非常常见，不会使读者感到困惑。然而，读者很可能会皱眉，如果你传递它的价值，他们期望你做这个优化，否则他们会认为你的程序写得很差。