FSharp.Core 没有优化？答案

【问题标题】：FSharp.Core not optimized?FSharp.Core 没有优化？
【发布时间】：2010-08-24 09:51:12
【问题描述】：

我最近检查了 F# 应用程序的性能，在挖掘 CIL 时我发现 FSharp.Core（用于 .NET v4.0）包含几个 nop 指令、许多未使用的变量和仅通过 stloc/ldloc 指令序列写入/读取一次。
我调查了可能的原因，我注意到即使在发布模式下，F# 程序集也包含 --debug:pdbonly 指令，并且无法禁用它并从项目设置 UI 切换到 --debug-。
我想知道 FSharp.Core 的编译设置是否有特定的选择，如果有，那是什么。否则期望运行时的完全优化版本是否合法？

【问题讨论】：

相关问题stackoverflow.com/questions/1612543/…
--debug:pdbonly 对于发布代码是正常的，这仅包括有限的调试信息并允许对堆栈进行解码。所有的 Windows（包括 .NET）都是这样构建的：这就是 MS 可以在其符号服务器上提供符号的方式。
@Richard：谢谢。我怀疑与调试相关的原因，但是我想知道更优化的版本是否会带来性能优势......在性能关键，计算绑定的应用程序中，人们希望能够牺牲调试能力来挤压每一个CPU周期...
@emaster70：PDB 仅调试信息没有性能影响，我对您问题的核心不做评论。
您的分析是否发现了 F# 核心库的特定问题？我希望 JIT 编译器忽略任何 nop，所以我不希望这会引入任何实际性能问题。

标签： f# cil

【解决方案1】：

这个问题的 cmets 似乎已经回答了大约 90% 的问题；重申一下：

Universe 中几乎所有发布的二进制文件都使用 --debug:pdbonly 进行编译
即使 IL 代码不是最佳的，由于 JIT 对其进行优化，这可能不会对实际世界产生任何影响

当然，F# 编译器可以通过各种方式生成更好的代码（这可能适用于每个编译器）；如果您分析您的应用程序并发现一些不好的地方（例如，与来自 C# 的可比较代码存在很大差异），那么您可以通过邮寄 fsbugs 让 F# 团队知道。但要先测量。

【讨论】：

【解决方案2】：

否则期望运行时的完全优化版本是否合法？

您建议的更改不能被合理地视为优化。两者都是无害的，将被 VM 编译掉。 ISTR，mutation 用于代替堆栈，因为基于堆栈的 VM 可以堆栈溢出。这就是 F# 正确地解决了 CLR 中的错误。

【讨论】：