caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Francois Berenger <berenger@riken.jp>
To: caml-list@inria.fr
Subject: Re: [Caml-list] exn vs option
Date: Thu, 05 Apr 2012 10:29:21 +0900	[thread overview]
Message-ID: <4F7CF571.9030706@riken.jp> (raw)
In-Reply-To: <CABkc=AOp-RwZDBFHMSP0inCSrMaEmR5Geh6L9q8p+K_kpjDrbQ@mail.gmail.com>

I think there was an article about options versus exceptions
in the OCaml journal.

If I remember well, the exceptions were faster, but I can't
find back the exact benchmark and context of this assertion.

Regards,
F.

On 04/05/2012 07:10 AM, Julien Verlaguet wrote:
> 2 more use cases:
>
> 1) When writing a deep recursion
> Throwing an exception will directly jump to your "catch" block without
> having to unfold every return call site on the stack one by one. Which
> can be much faster if the recursion is very "deep".
>
> 2) When your exception is exceptional :-)
> If Not_found is never caught, then using exceptions is faster than
> option because you don't have to allocate to perform the "find"
> operation (the difference should be minimal though).
> Plus it makes your code more readable, you don't have to match on the
> return value of the find.
> This use case makes sense if you don't intend to catch Not_found, when
> Not_found is a bug, period.
>
> Le 4 avril 2012 13:38, John Carr <jfc@mit.edu <mailto:jfc@mit.edu>> a
> écrit :
>
>
>     When thinking about performance, consider the "try" keyword to take time
>     to execute.  A try block pushes an exception handler onto a stack and
>     pops the stack on exit.  The try block may also interfere with tail call
>     optimizations.
>
>     A loop like
>
>       for i = 0 to 10000000 do try ... done
>
>     executes "try" 10000001 times and will run much more slowly than
>
>       try for i = 0 to 10000000 do ... done
>
>     where "try" only executes once.
>
>     I use options where performance matters, in frequently executed code
>     where the amount of computation is not much more than the overhead of
>     a try...with.  For example, I have variants of List.assoc that return
>     options instead of raising exceptions.
>
>     Where performance doesn't matter, i.e. the amount of code in the block
>     is large or the block is rarely executed, I use exceptions or options
>     based on convenience.
>
>      > I benchmarked two programs, in one case the main function throw
>     an exception
>      > that is caught, in the other the function returns an option that
>     is pattern
>      > matched on.
>      >
>      > I noticed that, whether the exception is thrown or not, the
>     option version is
>      > always faster.
>      >
>      > Is there any case where it makes sense, performance wise, to use
>     exception
>      > instead of 'a option ?
>
>     --
>     Caml-list mailing list.  Subscription management and archives:
>     https://sympa-roc.inria.fr/wws/info/caml-list
>     Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>     Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>


  reply	other threads:[~2012-04-05  1:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-04 20:25 Pierre Chopin
2012-04-04 20:38 ` John Carr
2012-04-04 22:10   ` Julien Verlaguet
2012-04-05  1:29     ` Francois Berenger [this message]
2012-04-05  6:45 ` Raphael Proust
2012-04-05  7:53   ` Benedikt Grundmann
2012-04-05  9:05 ` Goswin von Brederlow
2012-04-05  9:50   ` Daniel Bünzli
2012-04-11 10:26     ` Goswin von Brederlow
2012-04-11 10:32       ` David House
2012-04-11 10:36         ` David House
2012-04-05 20:19   ` Pierre Chopin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7CF571.9030706@riken.jp \
    --to=berenger@riken.jp \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).