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
>
>
next prev parent 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