调试与发布性能

Question

我遇到了以下段落：

  

在Visual Studio中编译代码时，IDE中的“调试与发布”设置对性能几乎没有差别......生成的代码几乎相同。 C＃编译器并没有真正进行任何优化。 C＃编译器只是吐出IL ...而在运行时它是执行所有优化的JITer。 JITer确实具有调试/释放模式，这对性能产生巨大影响。但这并不能决定你是否运行项目的调试或发布配置，而是关闭是否附加调试器。“

来源为here，播客为here。

有人可以引导我查看可以证明这一点的微软文章吗？

Google搜索“ C＃debug vs release performance ”主要返回的结果是“ Debug有很多性能损失”，“发布已优化 “和”不要将调试部署到生产“。

Answer 1

部分正确。在调试模式下，编译器为所有变量发出调试符号，并按原样编译代码。在发布模式中，包括一些优化：

• 未使用的变量根本无法编译
• 如果证明它们是不变量
，编译器会从循环中取出一些循环变量
• #debug指令下编写的代码不包括在内等。

其余的由JIT决定。

修改：完整的优化列表here由Eric Lippert

提供

Answer 2

没有任何文章可以“证明”有关性能问题的任何内容。证明关于变更对性能影响的断言的方法是尝试两种方式并在现实但受控制的条件下对其进行测试。

你问的是关于表现的问题，所以很明显你关心表现。如果您关心性能，那么正确的做法是设置一些性能目标，然后自己编写一个测试套件，跟踪您实现这些目标的进度。一旦你有了这样的测试套件，你就可以轻松地使用它来自己测试语句的真实性或虚假性，例如“调试版本更慢”。

此外，您将能够获得有意义的结果。 “较慢”毫无意义，因为尚不清楚它是慢一毫秒还是二十分钟慢。 “在现实条件下慢10％”更有意义。

花费时间在网上研究这个问题，建立一个回答问题的设备。通过这种方式，您将获得更准确的结果。您在线阅读的任何内容都只是猜测关于可能发生的事情。你自己收集的事实的原因，而不是其他人猜测你的程序可能会如何表现的原因。

Answer 3

我无法对性能发表评论，但建议“不要将调试部署到生产”仍然只是因为调试代码在大型产品中通常会有很多不同的东西。首先，您可能会激活调试开关，而另一个可能会有额外的冗余完整性检查和调试输出，这些都不属于生产代码。

Answer 4

来自msdn social

  

没有详细记录，这是什么   我知道。编译器发出一个   的例子   System.Diagnostics.DebuggableAttribute。   在调试版中，   IsJitOptimizerEnabled属性是   是的，在发布版本中   假。你可以看到这个属性   使用ildasm.exe

的程序集清单      

JIT编译器使用此属性   禁用可能的优化   使调试变得困难。那些   像代码一样移动代码   循环不变的提升。在选中   例如，这可以产生很大的不同   在表现。但通常不会。

     

将断点映射到执行   地址是调试器的工作。   它使用.pdb文件和信息   由JIT编译器生成的   提供IL指令代码   地址映射。如果你愿意的话   您自己的调试器，您可以使用   ICorDebugCode :: GetILToNativeMapping（）。

由于禁用了JIT编译器优化，因此调试部署基本上会变慢。

Answer 5

你读到的内容非常有效。由于JIT优化，版本通常更精益，不包括调试代码（#IF DEBUG或[条件（“DEBUG”）]），最小的调试符号加载，并且通常不考虑更小的组件，这将减少加载时间。由于更广泛的PDB和加载的符号，在VS中运行代码时性能不同更明显，但如果单独运行它，性能差异可能不太明显。某些代码将优于其他代码，并且使用与其他语言相同的优化启发式方法。

Scott对内联方法优化here

有很好的解释

请参阅this article，其中简要说明了为什么ASP.NET环境中的调试和发布设置不同。

Answer 6

您应该注意的一点是，关于性能以及调试器是否附加，这让我们感到意外。

我们有一段代码，涉及许多紧密循环，似乎需要永远调试，但它自己运行得很好。换句话说，没有遇到问题的客户或客户，但是当我们进行调试时，它似乎像糖蜜一样运行。

罪魁祸首是其中一个紧密循环中的Debug.WriteLine，它会抛出数千条日志消息，这些消息会在一段时间后从调试会话中消失。似乎当连接调试器并监听这样的输出时，会产生开销，这会减慢程序的速度。对于这个特定的代码，它自己的运行时间为0.2-0.3秒，连接调试器时为30秒以上。

简单的解决方案，只需删除不再需要的调试消息。

Answer 7

在msdn网站...

  

发布与调试配置

     

当你还在努力的时候   项目，你通常会建立你的   使用debug进行应用程序   配置，因为这个   配置使您可以查看   变量和控制的价值   在调试器中执行。您可以   还可以在中创建和测试构建   发布配置以确保   你没有介绍任何错误   只显示在一种类型的构建或   另一个。在.NET Framework中   编程，这样的bug很少见，   但它们可以发生。

     

当您准备好分发您的   应用于最终用户，创建一个   发布版本，这将是很多   较小，通常会有很多   比表现更好   相应的调试配置。您   可以在中设置构建配置   “项目设计器”的“构建”窗格，或   在构建工具栏中。更多   信息，请参阅构建配置。

Answer 8

我最近遇到了性能问题。产品完整列表花费了太多时间，大约80秒。我调整了数据库，改进了查询，没有任何区别。我决定创建一个TestProject，我发现在4秒内执行了相同的过程。然后我意识到项目处于调试模式，测试项目处于发布模式。我将主项目切换到发布模式，产品完整列表只需4秒即可显示所有结果。

总结：调试模式比运行模式慢得多，因为它保持调试信息。您应该始终以Relase模式部署。如果包含.PDB文件，您仍可以获得调试信息。这样，您可以使用行号记录错误，例如。

Answer 9

调试和释放模式有所不同。有一个工具Fuzzlyn：这是一个模糊器，利用Roslyn生成随机的C＃程序。它在.NET Core上运行这些程序，并确保以调试和发布模式进行编译时它们给出相同的结果。

使用此工具发现并报告了许多错误。

Answer 10

在很大程度上，这取决于你的应用程序是否受计算限制，并且并不总是很容易分辨，就像在Lasse的例子中那样。如果我对它正在做什么有任何疑问，我会暂停几次并检查堆栈。如果有一些额外的事情我并不真正需要，那就立即发现它。

Answer 11

关闭日志记录和调试 在构建要发布的应用程序之前，请确保停用日志记录并禁用调试选项。您可以通过在源文件中删除对 Log 方法的调用来停用日志记录。您可以通过从清单文件中的标记中删除 android:debuggable 属性，或在清单文件中将 android:debuggable 属性设置为 false 来禁用调试。此外，删除在您的项目中创建的所有日志文件或静态测试文件。

https://developer.android.com/studio/publish/preparing

How to remove all debug logging calls before building the release version of an Android app?

Difference between debug and release apks

开发、测试、验收和生产

https://blog.chizobaogbonna.me/having-different-variants-debug-staging-release-of-your-app-on-a-single-device-2efdcaaf4950 https://ajiethkumar.wordpress.com/2017/04/07/it-environments-management/ https://www.onlinecomputertips.com/support-categories/networking/646-what-is-a-dmz 内部网络 vs 外围

https://dev.to/aws-builders/jump-over-a-hurdle-of-working-with-amplify-backend-environment-c77

https://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_production https://oroinc.com/b2b-ecommerce/blog/testing-and-staging-environments-in-ecommerce-implementation/

https://medium.com/the-liberators/want-to-be-agile-drop-your-dtap-pipeline-7dcb496fe9e3

https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained/ https://blogs.vmware.com/management/2013/11/features-for-thought-series-vcac-6-0-simplify-application-deployments-across-any-environment.html https://enterprise.arcgis.com/en/server/10.3/administer/linux/arcgis-server-in-development-staging-and-production-environments.htm https://learn.timextender.com/courses/259790/lectures/4029947 https://humanitec.com/blog/kubernetes-environments-basics https://blogs.oracle.com/openomics/leveraging-a-disaster-recovery-site-for-development-part-2 https://doc.oroinc.com/cloud/environments/