当我比较 F# 为seq{}
表达式生成的IL
代码与为用户定义的计算工作流生成的代码时,很明显seq{}
的实现方式非常不同:它生成的状态机类似于 Once C# 用于其迭代器方法的状态机。 另一方面,用户定义的工作流会按预期使用相应的构建器对象。
所以我想知道 - 为什么会有差异?
这是出于历史原因,例如"seq 在工作流之前就存在"吗?
或者,是否有显著的性能要获得?
还有其他原因吗?
这是 F# 编译器执行的优化。据我所知,它实际上是后来实现的 - F# 编译器首先具有列表推导式,然后是计算表达式的通用版本(也用于seq { ... }
),但效率较低,因此在以后的版本中添加了优化。
主要原因是这消除了许多分配和间接。假设您有类似的东西:
seq { for i in input do
yield i
yield i * 10 }
使用计算表达式时,这将转换为以下内容:
seq.Delay(fun () -> seq.For(input, fun i ->
seq.Combine(seq.Yield(i), seq.Delay(fun () -> seq.Yield(i * 10)))))
有几个函数分配,For
循环始终需要调用 lambda 函数。优化将其转换为状态机(类似于 C# 状态机),因此生成的枚举器上的MoveNext()
操作只是改变类的某些状态,然后返回...
您可以通过为序列定义自定义计算构建器来轻松比较性能:
type MSeqBuilder() =
member x.For(en, f) = Seq.collect f en
member x.Yield(v) = Seq.singleton v
member x.Delay(f) = Seq.delay f
member x.Combine(a, b) = Seq.concat [a; b]
let mseq = MSeqBuilder()
let input = [| 1 .. 100 |]
现在我们可以测试这个(在 F# 交互式中使用 #time
):
for i in 0 .. 10000 do
mseq { for x in input do
yield x
yield x * 10 }
|> Seq.length |> ignore
在我的计算机上,使用自定义mseq
生成器时,这需要 2.644 秒,但在使用内置优化的seq
表达式时,这只需要 0.065 秒。因此,优化使序列表达式的效率显著提高。
从历史上看,计算表达式("工作流")是序列表达式的概括:http://blogs.msdn.com/b/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspx。
但是,答案肯定是可以获得显着的性能。我无法找到任何可靠的链接(尽管在 http://blogs.msdn.com/b/dsyme/archive/2007/11/30/full-release-notes-for-f-1-9-3-7.aspx 中提到了"与序列表达式中的'when'过滤器相关的优化"),但我确实记得这是一个在某个时间点进入的优化。我想说的好处是不言而喻的:序列表达式是一种"核心"语言功能,值得进行任何优化。
同样,您将看到某些尾部递归函数将优化为循环,而不是尾部调用。