与模式匹配相比，`Option.bind`是否有性能成本？
与模式匹配相比，`Option.bind`是否有性能成本？
提问于 2022-10-12 12:52:58
我看到了一些类似于这样的OCaml代码(简化的例子)：
match x_opt with
| Some x ->
(match do_some_stuff_with_x... with
| Some y -> do_some_stuff_with_y...
| None -> None
)
| None -> None以下备选方案是否有高性能成本？(特别是闭包中的内存使用)？
(* using core_kernel's Option module *)
x_opt
|> Option.bind ~f:(fun x -> do_some_stuff_with_x....)
|> Option.bind ~f:(fun y -> do_some_stuff_with_y....)可能的答案：
-
Option.bind版本可以任意昂贵，这取决于您在 - flambda上关闭的内容通常是足够聪明的，可以优化闭包(如rustc
- )。
Stack Overflow用户
回答已采纳
发布于 2022-10-12 17:16:10
绑定版本创建闭包的开销可能很小，这通常是由flambda优化的。即使没有创建闭包，例如，当绑定函数没有捕获外部上下文中的任何内容时(比如在Option.bind ~f:Option.return中)，额外调用的开销也很小。
除非在一个非常热的循环中运行，否则所有这些间接费用都可以被认为是可以忽略不计的。因此，除非您分析并发现这是一个问题，否则尝试使用在给定情况下最易读的样式。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/74042159
复制相关文章
相似问题
腾讯云开发者
