OCaml 异常的表现 [英] OCaml performance of exceptions

问题描述

我经常读到异常有点慢，如果性能有问题，应该避免异常(例如，在 Java、F# 等中).这是否适用于常见的 OCaml 函数，例如 Hashtbl.find，它会为未找到的元素返回异常?

I've often read that exceptions are somewhat slow and should be avoided if performance is an issue (for instance, in Java, F#, etc). Does that apply to common OCaml functions such as Hashtbl.find, which return exceptions for elements not found?

特别是，如果我希望我的应用程序高效，我是否应该在调用 Hashtbl.find 之前始终使用例如 Hashtable.mem 来测试元素成员资格?或者 mem 函数的额外比较是否会对性能产生负面影响?

In particular, if I want my application to be efficient, should I always test element membership using, for instance, Hashtable.mem before calling Hashtbl.find? Or would the extra comparison of the mem function negatively impact performance?

推荐答案

OCaml 异常处理使引发和捕获异常的速度非常快 -- 参见 this SO thread 了解有关如何实现的内部详细信息.我没有仔细对它进行精确的基准测试，但我的随机猜测是它在间接函数调用的范围内.

OCaml exception handling make raising and catching exceptions extremely fast -- see this SO thread for internal details on how it's implemented. I haven't taken care to benchmark it precisely, but my random guess would be that it is in the ballpark of an indirect function call.

众所周知，OCaml 异常与语言的其余部分成比例，比 F# 的异常要快得多——这会导致人们将代码从 OCaml 移植到 F# 时出现性能问题.在 OCaml 中，异常不会导致性能问题.

It is known that OCaml exceptions are significantly faster, in proportion to the rest of the language, than exceptions of F# for example -- this gave rise to performance problem for people porting their code from OCaml to F#. In OCaml, exceptions don't cause performance problems.

在Hashtbl.find 之前调用Hashtbl.mem 可能比捕获异常要慢.惯用的风格往往是 try Hashtbl.find .. with Not_found ->....

Calling Hashtbl.mem before Hashtbl.find is likely to be slower than catching the exception. The idiomatic style tends to be try Hashtbl.find .. with Not_found -> ....

也就是说，在 OCaml 社区中有一个明智的运动，即使用更明确的错误处理风格，使用 option 类型而不是异常.其原理不是基于性能，而是基于类型检查器可以阻止您忘记处理错误情况的事实.在设计全新的 API 时，我更喜欢这样做.使用引发异常的第三方函数时，请确保立即捕获所有可能的异常；不这样做通常是一种设计味道，应该非常合理.

That said, there is a sensible movement in the OCaml community to use more explicit error handling style, using option types rather than exceptions. The rationale is not based on performances, but on the fact that the type-checker then stop you from forgetting to handle an error situation. I would prefer that when designing a fresh new API. When using a third-party function that raise exceptions, make sure to catch all possible exceptions immediately; doing otherwise is a design smell in general and should be very heavily justified.

由于它们的便利性，OCaml 异常也经常用作纯粹的控制流机制(而不是发出罕见的故障情况信号).你会遇到这样的代码:

Due to their convenience, OCaml exceptions are also often used as a pure control-flow mechanism (and not to signal a rare failure condition). You will encounter code such as:

try
  for i = 0 to .... do
    if .. then raise Exit
  done; false
with Exit -> true

最后，我觉得您可能对实现选择采取了错误的方法.询问有关表演的一般性微问题通常不是可行的方法.首先考虑正确性和可读性.性能问题通常应稍后出现，并且仅在可衡量/可分析的情况下出现.

Finally, I feel that you might be taking a bad approach to implementation choices. Asking general micro-questions about performances is generally not the way to go. Think of correctness and readability first. Performance questions should generally come later, and only in situation where it is measurable/profilable.

这篇关于OCaml 异常的表现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！