在 Release 构建模式下进行分析时，生成的代码真的是 Release-build-mode-optimized 吗？答案

【问题标题】：When profiling in Release build mode, is the generated code really Release-build-mode-optimized?在 Release 构建模式下进行分析时，生成的代码真的是 Release-build-mode-optimized 吗？
【发布时间】：2019-04-16 20:43:52
【问题描述】：

我想知道：当 .Net 在抛出异常时在 Release 构建中生成堆栈跟踪时，行号通常是关闭的，而且在分析源代码时应该存在的一些堆栈帧甚至没有打印出来，因为它们 - 大概 -优化了。

因此，当 Visual Studio 表示在 CPU 对发布版本进行采样时在方法 X 上花费了大量时间时，这是否值得信任，或者它是否也可能由于优化而被关闭？

【问题讨论】：

您在询问什么结果，为什么您认为它们不准确？
我认为您可以确定 Visual Studio 的分析考虑了编译器优化。您对此有实际问题吗？
我认为这需要链接 Speed Rant：ericlippert.com/2012/12/17/performance-rant 基本上在 JiT 编译的垃圾收集运行时中获得高可靠性基准是很难的。

标签： c# .net visual-studio profiling

【解决方案1】：

分析器不关心您是在发布模式还是在调试模式下构建代码。无论发出什么代码，它都会对其进行分析。 profiling 的主要目标是测量各种与性能相关的指标并定位瓶颈。因此，探查器被设计成侵入性最小，以便能够进行足够准确的测量。通常，您会分析优化的代码，因为这是在生产系统上使用的代码。

关于堆栈跟踪，某些堆栈帧可能丢失的原因通常是由于方法内联，这是 JIT 编译器执行的一项重要优化。因此，如果 A 调用 B，而 B 又调用 C，并且如果 JIT 编译器将 B 内联到 A 中，那么调用堆栈将显示 A 调用了 C，并且即使 B 存在于源代码中，也将没有框架。此外，一些堆栈帧可能会丢失，因为分析器没有足够的调试信息，因此无法完全遍历堆栈。同样，源代码行号可能不匹配，因为 JIT 编译器可能会重新排列代码或删除一些代码，从而难以在本机代码和源代码之间进行准确的映射。所以你最终会看到一个近似的映射。

【讨论】：

可能都是这样，但这如何回答我的问题？
@EugeneBeresovsky 你问“所以当 Visual Studio 说在 CPU 对发布版本进行采样时在方法 X 上花费了很多时间时，这是可以信任的，还是由于优化也可以关闭？”我的回答是“是的，无论是否启用优化，都可以信任它，无论发出什么代码都会被分析。”我误解你的问题了吗？
当我无法信任堆栈跟踪时，我想了解为什么我应该信任分析器。 CPU 采样也在收集堆栈跟踪，那么为什么分析器可以经常做（每秒很多次），抛出异常时这是不可能的 - 通常很少发生的事情，可以（并且有帮助）花费更多是时候弄清楚真正的堆栈跟踪了。 OT：点赞您个人资料中的叙利亚视频。
@EugeneBeresovsky 我已经编辑了我的答案以解决您问题的第一部分。