【发布时间】：2011-03-26 04:20:16
【问题描述】：
Windows 服务在调试构建和发布构建之间可以获得多少性能提升（如果有），为什么？
【问题讨论】：
-
这是一个很好的问题，一些基准指标可以很好地解决，如果有人可以提供的话。
【发布时间】：2011-03-26 04:20:16
【问题描述】：
对于托管代码，除非您有很多有条件地为 DEBUG 构建编译的东西，否则应该没有什么区别 - IL 应该几乎相同。无论是否在调试器下运行，Jitter 的生成方式都不同 - 对 IL 的编译影响不大。
/optimize 在编译到 IL 时会做一些事情，但它们并不是特别激进。并且其中一些 IL 优化可能会由抖动优化处理，即使它们没有在 IL 中进行优化（例如删除 nops）。
详情请参阅 Eric Lippert 的文章http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx：
/optimize 标志不会大量改变我们的发射和生成逻辑。我们尝试始终生成简单、可验证的代码，然后在生成真实机器代码时依靠抖动进行繁重的优化。但我们将使用该标志集进行一些简单的优化。
阅读 Eric 的文章，了解有关 /optimize 的信息在 IL 生成方面确实有所不同。
【讨论】：
-
好东西...安全性如何？如果您发布/公开调试信息，检查是否会显示有关您的代码的更多信息？即使性能上的差异可以忽略不计，我也不会发布调试代码，除非我不得不这样做。
-
@Edward：我并不是真的提倡分发 DEBUG 构建，只是说您可能不应该期望 DEBUG 和 RELEASE 构建之间的性能存在重大差异。此外，我认为 DEBUG 构建在程序集本身中没有更多细节 - 调试信息位于 .pdb 文件中，您不需要分发该文件。 .NET 程序集通常很容易反汇编/反编译（请参阅反射器工具）。如果您担心逆向工程，有一些混淆工具可以帮助您解决这个问题，但我对它们一无所知。
-
谢谢...我忘了 .pdb 有调试信息。许多混淆工具不是完全证明的并且可能很昂贵。我一直认为，如果有人真的想加入，他们就会加入。我应该花更多时间创新，少花时间保护。
-
@Edward：+1 表示“多花时间创新，少花时间保护”。保护您的代码的唯一真正方法是永远不要让用户拥有它，例如，仅将其作为服务运行。如果用户有你的代码，他们可以反汇编它。他们几乎从不打扰。使用法律辩护而不是技术辩护。
好吧，虽然问题是重复的，但我觉得原始问题中的一些更好的答案在最底部。就我个人而言，我见过调试模式和发布模式之间存在明显差异的情况。 （例如：Property performance，在调试和发布模式下访问属性之间存在 2 倍的差异）。这种差异是否会出现在实际的软件中（而不是像程序一样的基准测试）是有争议的，但我已经看到它发生在我从事的一个产品中。
来自尼尔对原始问题的回答，来自msdn social：
没有很好的记录，这是我所知道的。编译器发出 System.Diagnostics.DebuggableAttribute 的一个实例。在调试版本中，IsJitOptimizerEnabled 属性为 True，在发布版本中为 False。您可以使用 ildasm.exe 在程序集清单中看到此属性。
JIT 编译器使用此属性来禁用会使调试变得困难的优化。像循环不变提升一样移动代码的那些。在选定的情况下，这会对性能产生很大影响。不过通常不会。
将断点映射到执行地址是调试器的工作。它使用 JIT 编译器生成的 .pdb 文件和信息，该编译器提供 IL 指令到代码地址映射。如果您要编写自己的调试器，您将使用 ICorDebugCode::GetILToNativeMapping()。
【讨论】：