问在将CLR调试器附加到进程时，.NET代码运行速度是否较慢？

EN

最重要的是:工具+选项，调试，常规，抑制模块加载的JIT优化。如果您想调试发布代码并获得类似的性能，则需要将其关闭。然而，这确实增加了调试代码的难度，JIT优化器将在CPU寄存器中存储局部变量(Watch不起作用)，并对代码进行重新排序和内联(单步执行很奇怪)。

然后是由编译器自动生成的DebuggableAttribute。它的IsJITOptimizerEnabled和IsJITTrackingEnabled属性很重要。首先，它们的作用是使局部变量的存活时间比必要的长一点，从而防止垃圾收集器收集您可能希望在调试器中检查的引用。很容易避免，只需调试发布版本，而不是调试版本。

然后，在你的程序中会发生一些特定的事情，唤醒调试器，使其窃取CPU周期：

当你的程序抛出异常时，

• 。调试器在它被抛出之前对它进行一次尝试。称为“第一次机会通知”，您可以在输出窗口中看到它。这就是Debug + Exceptions对话框工作的原因。当您的程序加载或卸载DLL时，
• 会大大减慢异常处理的速度。加载时会发生很多事情，调试器会尝试为DLL查找符号。检查是否需要激活任何断点。并在“输出”窗口中显示通知。这通常只会使程序的启动速度变慢，特别是当您打开了混合模式调试时。当您使用带有DefaultTraceListener、Debug.Write/Line()方法或启用了宿主进程的Console.Write/Line时，
• 。输出出现在输出窗口中，大大减慢了这些调用的速度。当你的程序中的线程启动或停止时，
• 。在输出窗口中可见。让它减慢你的程序将是一个设计上的错误。

就是这样，调试器不会妨碍你的代码，只要它不做上面列出的事情，它就会让你的代码全速运行。像ASP.NET和Silverlight这样的运行时环境是特殊的，可能会有额外的开销。在64位操作系统上调试任何CPU程序也是如此，这需要远程调试器，因为VS仅为32位。

是的，我已经看到了相当大的不同。

特别是，当抛出异常时，当附加调试器时，它们花费的时间要长得多。还有一些其他重要的优化可以影响行为-例如，当未附加调试器时，垃圾收集器会更具侵略性。

为什么不直接记录异常而不是进入调试器呢？抛开其他事情不谈，这意味着如果你想回到过去，看看昨天发生的异常，并将它与刚刚发生的异常进行比较，这很容易……更难回到过去:)

附加调试器会禁用一些JIT优化--例如函数内联。

http://msdn.microsoft.com/en-us/library/bb384548.aspx

你的表现可能会更差。