调试和发布版本之间的性能差异

C编译器本身不会在发布版本中对发出的IL进行很大的更改。值得注意的是,它不再发出允许在大括号上设置断点的NOP操作码。最大的一个是内置在JIT编译器中的优化器。我知道它进行了以下优化:

• 方法内联。方法调用被方法的代码注入所代替。这是一个很大的问题,它使得属性访问器本质上是免费的。

• CPU寄存器分配。局部变量和方法参数可以保持存储在CPU寄存器中,而不必(或不经常)存储回堆栈帧。这是一个很大的问题,值得注意的是它使调试优化代码变得如此困难。并给予 不稳定的 关键词一个意思。

• 循环展开。通过在体中重复代码4次并减少循环次数,改进了具有小实体的循环。降低分支成本并改进处理器的超级标量执行选项。

• ... /}完全消除。这可能是由于不断的折叠和内联。其他情况是JIT编译器可以确定代码没有可能的副作用。这种优化使分析代码变得如此棘手。

• 公共子表达式消除。x=y+4;z=y+4;变为z=x;在dest[ix+1]=src[ix+1]等语句中非常常见;为可读性而编写,不引入helper变量。不需要牺牲可读性。

• 不断的折叠。x=1+2;变为x=3;这个简单的例子在编译器早期捕获,但在JIT时发生,其他优化使之成为可能。

• 复制传播。x=a;y=x;变成y=a;这有助于寄存器分配器做出更好的决策。在x86抖动中这是一个很大的问题,因为它几乎没有寄存器可以使用。让它选择正确的是至关重要的性能。

这些是非常重要的优化,可以使 例如,当您分析应用程序的调试版本并将其与发布版本进行比较时,需要处理差异。不过,只有当代码在关键路径上时,你编写的代码的5%到10%才是真正重要的 事实上

这些优化对程序执行时间的有效结果通常会受到在其他地方运行的代码的影响。读取文件、执行dbase查询等,使JIT优化器所做的工作完全不可见。不过也不介意:)

JIT优化器是相当可靠的代码,主要是因为它已经被测试了数百万次。在程序的发布版本中很少有问题。但它确实发生了。x64和x86抖动都有结构问题。x86抖动在浮点一致性方面有问题,当浮点计算的中间部分以80位精度保存在FPU寄存器中而不是在刷新到内存时被截断时,会产生细微的不同结果。

1. 是的,有许多性能差异,这些差异确实适用于您的代码。Debug很少进行性能优化,发布模式也很少;

2. 唯一依赖于 DEBUG 常量在发布版本中的执行方式可能不同。除此之外,你不应该看到任何问题。

依赖于 常数是 Debug.Assert() [Conditional("DEBUG)"] 定义。这意味着它还取决于 常数,此值不包含在版本生成中。

这在很大程度上取决于应用程序的性质。如果你的应用程序很重UI,你可能不会注意到任何区别,因为连接到现代计算机的最慢组件是用户。如果使用一些UI动画,则可能需要测试在调试生成中运行时是否能察觉到任何明显的延迟。

这基本上是一个设计上的折衷。如果您是在DEBUG build下发布的,那么如果用户遇到问题,您可以获得更有意义的回溯,并且可以执行更灵活的诊断。通过在调试版本中发布,还可以避免优化器产生模糊 Heisenbugs .

• 我的经验是,中型或大型应用程序在发布版本中的响应明显更高。试试你的应用程序,看看感觉如何。

• 有一件事会让您对发布版本产生困扰,那就是调试生成代码有时可以抑制竞争条件和其他与线程相关的错误。优化的代码可以导致指令重新排序,更快的执行会加剧某些竞争条件。

它可能包含丑陋的代码来支持编辑和继续,或者谁知道还有什么。据我所知,这种情况只在VB中发生,而不是在C中# (注:原帖子标记为C#) ,但它仍然应该给出暂停的理由,说明微软认为他们可以对调试版本做些什么。事实上,在.NET 4.0之前,VB代码泄漏的内存与您为支持Edit和Continue而构造的事件的对象实例数成比例。(尽管据报道这是根据 https://connect.microsoft.com/VisualStudio/feedback/details/481671/vb-classes-with-events-are-not-garbage-collected-when-debugging ,生成的代码看起来很糟糕,创建 WeakReference 对象并在 )我当然不希望在生产环境中有这种调试支持!

以我的经验来看,发布模式中最糟糕的事情就是那些晦涩难懂的“发布错误”。由于IL(中间语言)是在发布模式下优化的,因此存在在调试模式下不会出现的错误的可能性。还有其他关于这个问题的问题: Common reasons for bugs in release version not present in debug mode

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

我想说,1)很大程度上取决于你的执行情况。通常,差别并不大。我做了很多测量,但常常看不出有什么不同。如果使用非托管代码、大量的数组和类似的东西,性能差异会稍微大一些,但不是一个不同的世界(如C++)。2) 通常在发布代码中,显示的错误较少(公差较高),因此开关应该工作正常。

    **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:
    More optimized code
    Some additional instructions are removed and developer can’t set a breakpoint on every source code line.
   1) Less memory is used by the source code at runtime.
   2) Scripts & images downloaded by webresource.axd are cached.
   3) It has small size, and runs fast.
   4) Scripts & images downloaded by webresource.axd are cached.
   5) It has small size, and runs fast.