我知道我的答案很晚，我的答案并不完全是你想要的，但是，我认为一些坚实而简单的例子会很好。不管怎样，这段代码导致了调试和发布之间的巨大差异。代码是在Visual Studio 2019上用c++编写的。代码是这样的:

#include <iostream>

using namespace std;

unsigned long long fibonacci(int n)
{
    return n < 2 ? n : (fibonacci(n - 1) + fibonacci(n - 2));
}

int main()
{
    int x = 47;

    cout << "Calculating..." << endl;
    cout << "fib(" << x << ") = " << fibonacci(x) << endl;
}

编辑: 计算斐波那契数列的性能差异

                       Debug        Release         
                C++ x86 C++ x64 C++ x86 C++ x64 C# Debug    C# Release
Time (mSeconds) 99384.9 27799.1 11066.0 11321.5 95233.7 24566.0
Time (Seconds)  99.4    27.8    11.1    11.3    95.2    24.6

我的经验是，中等大小或较大的应用程序在发布版构建中反应明显更好。在您的应用程序中尝试一下，看看效果如何。 发布版本可能会让您感到困扰的一件事是，调试版本代码有时会抑制竞态条件和其他与线程相关的错误。优化的代码可能导致指令重新排序，更快的执行可能加剧某些竞争条件。

You should never release a .NET Debug build into production. It may contain ugly code to support Edit-and-Continue or who knows what else. As far as I know, this happens only in VB not C# (note: the original post is tagged C#), but it should still give reason to pause as to what Microsoft thinks they are allowed to do with a Debug build. In fact, prior to .NET 4.0, VB code leaks memory proportional to the number of instances of objects with events that you construct in support of Edit-and-Continue. (Though this is reported to be fixed per https://connect.microsoft.com/VisualStudio/feedback/details/481671/vb-classes-with-events-are-not-garbage-collected-when-debugging, the generated code looks nasty, creating WeakReference objects and adding them to a static list while holding a lock) I certainly don't want any of this kind of debugging support in a production environment!

    **Debug Mode:**
    Developer use debug mode for debugging the web application on live/local server. Debug mode allow developers to break the execution of program using interrupt 3 and step through the code. Debug mode has below features:
   1) Less optimized code
   2) Some additional instructions are added to enable the developer to set a breakpoint on every source code line.
   3) More memory is used by the source code at runtime.
   4) Scripts & images downloaded by webresource.axd are not cached.
   5) It has big size, and runs slower.

    **Release Mode:**
    Developer use release mode for final deployment of source code on live server. Release mode dlls contain optimized code and it is for customers. Release mode has below features:
   1) More optimized code
   2) Some additional instructions are removed and developer can’t set a breakpoint on every source code line.
   3) Less memory is used by the source code at runtime.
   4) Scripts & images downloaded by webresource.axd are cached.
   5) It has small size, and runs fast.

这在很大程度上取决于应用程序的性质。如果您的应用程序是ui密集型的，您可能不会注意到任何不同，因为连接到现代计算机的最慢的组件是用户。如果您使用一些UI动画，您可能想要测试在DEBUG版本中运行时是否能察觉到任何明显的延迟。

然而，如果您有很多计算量大的计算，那么您就会注意到差异(可能高达40%，正如@Pieter所提到的，尽管这取决于计算的性质)。

这基本上是一种设计权衡。如果您在DEBUG版本下发布，那么如果用户遇到问题，您可以获得更有意义的回溯，并且可以进行更灵活的诊断。通过在DEBUG版本中发布，你也可以避免优化器产生模糊的Heisenbugs。

在我的经验中，发布模式中最糟糕的事情就是晦涩的“发布漏洞”。由于IL(中间语言)是在发布模式下优化的，因此存在在调试模式下不会出现的错误的可能性。还有其他关于这个问题的SO问题: 在调试模式中不存在发布版本中的错误的常见原因

这种情况在我身上发生过一两次，一个简单的控制台应用程序在调试模式下运行得很好，但给定完全相同的输入，在发布模式下就会出错。这些bug极其难以调试(讽刺的是，根据发布模式的定义)。