性能差异调试与发布答案

【问题标题】：Performance difference Debug vs Release性能差异调试与发布
【发布时间】：2019-11-25 11:03:07
【问题描述】：

我发现各种来源表明 Visual Studio 的调试和发布版本几乎没有性能差异。

我正在使用 Visual Studio 2015 并编写了一个事件驱动的状态机框架。在我进行第一次性能测试后，由于框架每秒仅进行大约 13.000 次状态切换，因此遇到了问题。

但是，当我将它编译为发布版本时，我每秒获得了 150 万次状态切换。这对我来说是一个巨大的增长，但我无法解释这是从哪里来的。

可悲的是，我不能分享我的代码，因为它属于我的公司。

但我发现像这样的 for 循环已经在发布版本中运行得更快了。

for (auto i = 0; i < 2000000; i++)      
        my_machine.PushEvent(event);

此外，发布版本的内存使用量从 255 MB 下降到 67MB。内存被两个队列占用。

我希望这不会被标记为重复，但我想听听一些关于性能差异的意见。

【问题讨论】：

“我发现了各种来源，调试和发布版本应该几乎没有性能差异”，它们是（除了错误之外）？
“我发现了各种来源，它们与 Visual Studio 的调试和发布版本几乎没有性能差异。” - 忽略这些来源。他们显然不知道他们在谈论/写什么。使用 Visual Studio 编译器（以及任何其他编译器）进行调试（未优化）和发布（优化）构建之间存在巨大的性能差异。
我见过一些任务在发布模式下需要几分钟，而在调试模式下需要一天多的时间。减速很大程度上取决于您正在调试的代码。在上面的例子中，算法做了很多小的分配。
您的源代码来自完全不同的编程语言，并且还使用 .net 框架托管代码与没有 .net 的本机代码。
“但是当我将它编译为发布版本时，我每秒获得 150 万次状态切换。这对我来说是一个巨大的增长，但我无法解释这是从哪里来的。” - 它来自您的编译器优化器。 C++ 的设计目的是让编译器完全移除大量昂贵的抽象，并且优化器也有很多的技巧可以将你编写的慢代码变成非常高效的代码。当您不启用优化器时，代码将易于调试，但速度较慢。当您启用优化器时，代码会很快，但很难调试。

【解决方案1】：

我发现各种来源表明 Visual Studio 的调试和发布版本几乎没有性能差异。

这很可能是不正确的，或者被误解的信息^{...或者，显然，关于不同语言的信息}。万一误解，原来的说法可能是调试符号信息对性能没有影响，这是正确的。

无论如何，由_DEBUG（Visual Studio 特定）启用或由NDEBUG（控制断言的标准宏）禁用的额外调试操作确实有开销。开销有多大取决于程序的作用。如果它花费大部分时间等待硬盘或网络，那么可能不是很重要。如果它对容器执行大量操作，那么开销可能会更大。

更显着的性能差异将来自缺乏优化，优化是在发布版本中启用的，而不是在调试版本中。

【讨论】：

【解决方案2】：

许多生态系统中的发布版本关闭了调试信息并开启了性能优化。后者很可能是您看到的差异的原因。

如果您想对此进行测试，您可以提高调试版本的优化级别，看看它是否会产生更具可比性的性能。 Here's a list of optimization level arguments you could use - 我的猜测是发布版本使用 /O2 或 /Ox。

【讨论】：

谢谢，我会调查一下，但你不觉得性能提升有点疯狂吗？
并非如此。您描述了大约 100 倍的速度提升，虽然这绝对是相当可观的，但肯定还有一些编译器优化可以在适当的情况下产生相当大的收益 (this comes to mind)。
包含调试信息通常不会减慢您的应用程序的速度。它只是占用更多的磁盘空间。减慢调试构建的原因是没有运行优化器。在我工作的地方，我们实际上以优化的形式（为了性能）发布了我们的软件，但启用了调试符号（为了故障转储的可调试性）。启用调试符号不会减慢应用程序的速度，但会稍微减轻在优化代码中调试崩溃的痛苦。
@HWilmer 如果事实证明以后永远不会读取数组，则编译器可以通过优化完全删除在数组中写入超过一百万个元素的循环。所以不行; 100 倍似乎很公平