caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Julien Verlaguet <julien.verlaguet@gmail.com>
To: John Carr <jfc@mit.edu>
Cc: Pierre Chopin <pierre@punchup.com>, caml-list@inria.fr
Subject: Re: [Caml-list] exn vs option
Date: Wed, 4 Apr 2012 15:10:37 -0700	[thread overview]
Message-ID: <CABkc=AOp-RwZDBFHMSP0inCSrMaEmR5Geh6L9q8p+K_kpjDrbQ@mail.gmail.com> (raw)
In-Reply-To: <201204042038.q34KcPcj001730@outgoing.mit.edu>

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3140 bytes --]

  reply	other threads:[~2012-04-04 22:10 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 [this message]
2012-04-05  1:29     ` Francois Berenger
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='CABkc=AOp-RwZDBFHMSP0inCSrMaEmR5Geh6L9q8p+K_kpjDrbQ@mail.gmail.com' \
    --to=julien.verlaguet@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=jfc@mit.edu \
    --cc=pierre@punchup.com \
    /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).