我必须承认，通常我不会费心在程序中的Debug和Release配置之间切换，我通常选择Debug配置，即使程序实际上部署在客户的位置。
据我所知，如果不手动更改，这些配置之间的唯一区别是Debug定义了Debug常量，而Release检查了优化代码。
所以我的问题实际上是双重的:
这两种配置在性能上有很大差异吗?是否有任何特定类型的代码会导致性能上的巨大差异，或者它实际上并不那么重要? 是否有任何类型的代码可以在调试配置下正常运行，但在发布配置下可能失败，或者您能否确定在调试配置下测试并正常运行的代码在发布配置下也可以正常运行。
当前回答
我知道我的答案很晚，我的答案并不完全是你想要的，但是，我认为一些坚实而简单的例子会很好。不管怎样，这段代码导致了调试和发布之间的巨大差异。代码是在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
其他回答
我的经验是，中等大小或较大的应用程序在发布版构建中反应明显更好。在您的应用程序中尝试一下，看看效果如何。 发布版本可能会让您感到困扰的一件事是，调试版本代码有时会抑制竞态条件和其他与线程相关的错误。优化的代码可能导致指令重新排序，更快的执行可能加剧某些竞争条件。
我知道我的答案很晚，我的答案并不完全是你想要的，但是，我认为一些坚实而简单的例子会很好。不管怎样，这段代码导致了调试和发布之间的巨大差异。代码是在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
是的，存在许多性能差异，这些差异确实适用于您的所有代码。调试很少做性能优化，而发布模式做得很多; 只有依赖于DEBUG常量的代码在发布版本中才能有不同的表现。除此之外，你应该看不到任何问题。
依赖于DEBUG常量的框架代码的一个例子是DEBUG . assert()方法，它具有属性[条件("DEBUG)”)的定义。这意味着它也依赖于DEBUG常量，而这并不包含在发行版中。
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!
我会说
很大程度上取决于您的实现。通常情况下，差别并没有那么大。我做了很多测量，但经常看不到区别。如果你使用非托管代码，大量的巨大数组和类似的东西，性能的差异会稍微大一些，但不是一个不同的世界(像在c++中)。 通常在发布代码中会显示更少的错误(更高的容忍度)，因此开关应该可以正常工作。
