c++ - VS2008 C++ 优化器有时会产生较慢的代码吗？

Question

从 previous question 开始，我一直在使用我的发布版本中的优化器设置，看看使用编译器优化可以获得哪些好处。到目前为止，我一直在使用/Ob1(仅在明确给出 inline 的地方使用 inline)和/Oi(启用内部函数)。我尝试将其更改为包括/Ot(有利于快速代码)、/Oy(省略帧指针)和/Ob2(内联任何合适的)，令我惊讶的是，一个需要 2 小时 58 分钟的回归套件现在需要 3 小时 16 分钟。我的第一个假设是我自己的内联比编译器更激进，但是从/Ob2 回到/Ob1 只会将事情改进到 3h12m。我仍在运行更多测试，但似乎在某些情况下/Ot(有利于快速代码)实际上会减慢速度。该软件是多线程和计算密集型的(表面建模、操作和可视化)，并且已经根据剖面仪结果进行了大量手动优化。该程序还处理大量数据，并经常使用#pragma pack(4)。

所以问题是这样的。对于手动优化的程序，VS2008 中的编译器优化是否弊大于利？换句话说，是否存在编译器优化会降低性能的已知记录场景？ (n.b. 分析编译器优化的代码很痛苦，因此迄今为止的分析都是在未优化的代码上完成的)。

编辑 根据 Cody Gray 和其他人的建议，我已将/O2 添加到优化设置并重新执行我的测试套件。这导致运行时间为 3h01，与最低限度优化运行相当。鉴于(略有过时)MSDN guide lines on optimization并从 GOZ 发帖，我将检查/O1 以查看在我的情况下是否更小实际上更快。请注意，当前的 EXE 文件大约为 ~11mb。我还将尝试一起构建 VS2010，看看效果如何。

Edit2 使用/O1，运行时间为 3h00，11mb exe 小了 62k。请注意，这篇文章和之前链接的文章背后的原因是检查打开编译器优化的好处是否超过了分析和调试方面的缺点。在这个特定的例子中，它们似乎不是，尽管我承认对尝试的组合没有增加任何好处和一些明显降低的性能感到惊讶。 FWIW，根据这个previous thread ，我倾向于在设计时进行大部分优化，主要使用探查器来检查设计假设，我认为我会坚持使用这种方法。我将在 VS2010 上进行最后一次启用整个程序优化，然后就此结束。

感谢所有反馈!

Answer 1

documentation对于 /Ot 状态:

If you use /Os or /Ot, then you must also specify /Og to optimize the code.

因此您可能希望在测试中始终通过 /Og 和 /Ot。

就是说，/Ot 以牺牲程序大小为代价来支持快速代码，并且可以生成非常大的二进制文件，尤其是在大量内联的情况下。大型二进制文件难以利用处理器缓存。