F# ref-mutable vars 与对象字段答案

【问题标题】：F# ref-mutable vars vs object fieldsF# ref-mutable vars 与对象字段
【发布时间】：2011-02-25 22:09:09
【问题描述】：

我正在用 F# 编写一个解析器，它需要尽可能快（我希望在不到一分钟的时间内解析一个 100 MB 的文件）。像往常一样，它使用可变变量来存储下一个可用字符和下一个可用标记（即词法分析器和解析器都正确使用一个前瞻单元）。

我当前的部分实现对这些使用局部变量。由于闭包变量不能是可变的（有人知道原因吗？）我将它们声明为 ref：

let rec read file includepath =
    let c = ref ' '
    let k = ref NONE
    let sb = new StringBuilder()
    use stream = File.OpenText file

    let readc() =
        c := stream.Read() |> char
    // etc

我认为这有一些开销（我知道，不多，但我在这里尝试最大速度），而且有点不雅。最明显的替代方法是创建一个解析器类对象并将可变变量作为其中的字段。有谁知道哪个可能更快？是否有任何共识被认为是更好/更惯用的风格？我还缺少其他选择吗？

【问题讨论】：

你有没有考虑过这个任务可能是 I/O 限制而不是计算限制？如果它是使用 refs 或 mutables 绑定的 I/O 并不重要，那么不同的是使用异步编程模型来加载您的数据。异步加载数据块并进行处理可以让您在处理文件的早期部分时加载数据。在进行这种异步编程时，F# 异步工作流程有很大帮助。
如果您在将文本转换为 AST 时只需要 1.7 Mb/秒，您可以使用您能找到的任何解析器。一些 OCaml 解析器组合器在解析大而不那么简单的语法时显示 >30Mb/s。 FParsec 很好，您可以使用它轻松更改语法。
Robert，根据我的经验，解析往往受 CPU 限制，但您提出了一个很好的观点，即如果可以使其受 I/O 限制，那么异步处理值得研究。
ssp，每秒 30 MB 解析复杂语法无疑是一个令人印象深刻的数字。我可能会研究 FParsec 使用的技术。谢谢！

标签： parsing f# closures

【解决方案1】：

您提到局部可变值不能被闭包捕获，因此您需要改用ref。这样做的原因是闭包中捕获的可变值需要在堆上分配（因为闭包是在堆上分配的）。

F# 强制你明确地写这个（使用ref）。在 C# 中，您可以“捕获可变变量”，但编译器会在后台将其转换为堆分配对象中的字段，因此无论如何它都会在堆上。

总结就是：如果要使用闭包，需要在堆上分配可变变量。

现在，关于您的代码 - 您的实现使用 ref，它为您正在使用的每个可变变量创建一个小对象。另一种方法是创建具有多个可变字段的单个对象。使用记录，您可以编写：

type ReadClosure = {
  mutable c : char
  mutable k : SomeType } // whatever type you use here

let rec read file includepath = 
  let state = { c = ' '; k = NONE } 
  // ... 
  let readc() = 
    state.c <- stream.Read() |> char 
    // etc...

这可能会更高效一些，因为您分配的是单个对象而不是几个对象，但我预计差异不会很明显。

您的代码还有一个令人困惑的地方-stream 值将在函数read 返回后被释放，因此对stream.Read 的调用可能无效（如果您在read 之后调用readc完成）。

let rec read file includepath =    
  let c = ref ' '    
  use stream = File.OpenText file    
  let readc() =    
    c := stream.Read() |> char    
  readc

let f = read a1 a2
f() // This would fail!

我不太确定您实际上是如何使用readc 的，但这可能是一个需要考虑的问题。此外，如果您仅将其声明为辅助闭包，您可能会在不使用闭包的情况下重写代码（或使用尾递归显式编写代码，将其转换为带有可变变量的命令式循环）以避免任何分配。

【讨论】：

啊！我刚刚查看了生成的代码，我看到了发生了什么，内部函数使用的外部变量作为额外参数传递——在所有情况下都是如此，所以这就是为什么可变变量必须是 ref。因此，最有效的解决方案可能是为不可变的保留闭包方法，但将可变的设为全局变量，这样就不会分配堆。（read 是整个解析器函数，其他所有函数都是内部函数，所以 stream 会在整个工作完成后被释放。）谢谢！

【解决方案2】：

我做了以下分析：

let test() = 
    tic()
    let mutable a = 0.0
    for i=1 to 10 do
        for j=1 to 10000000 do
            a <- a + float j
    toc("mutable")
let test2() = 
    tic()
    let a = ref 0.0
    for i=1 to 10 do
        for j=1 to 10000000 do
            a := !a + float j
    toc("ref")

mutable 的平均值是 50ms，而 ref 是 600ms。性能差异是由于可变变量在堆栈中，而 ref 变量在托管堆中。

相对差异很大。但是，10^8 次访问是一个很大的数字。并且总时间是可以接受的。所以不要太担心 ref 变量的性能。请记住：

过早的优化是万恶之源。

我的建议是先完成解析器，然后再考虑优化它。在您实际运行该程序之前，您不会知道瓶颈在哪里。 F# 的一个优点是其简洁的语法和函数式风格很好地支持代码重构。一旦代码完成，优化它会很方便。 Here 是一个分析示例。

再举一个例子，我们每天都使用 .net 数组，它也在托管堆中：

let test3() = 
    tic()
    let a = Array.create 1 0.0
    for i=1 to 10 do
        for j=1 to 10000000 do
            a.[0] <- a.[0] + float j
    toc("array")

test3() 与 ref 的运行方式大致相同。如果您太担心托管堆中的变量，那么您将不再使用数组。

【讨论】：