OCaml执行例外 [英] OCaml performance of exceptions

查看:96
本文介绍了OCaml执行例外的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我经常读到,异常在某种程度上是缓慢的,如果性能是一个问题(例如,在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异常处理使异常的引发和捕获变得非常快-请参阅

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆