Re: [Caml-list] Performance penalty of exception handling

Re: [Caml-list] Performance penalty of exception handling

["Mark Adams"]

One problem is if your function that traps the exception is recursive - it
cannot be made tail recursive if the recursive call is within the 'try' ..
'with', which can cause stack overflow if it recurses thousands of times.

Mark Adams.

on 16/9/15 8:08 PM, Helmut Brandl <helmut.brandl@gmx.net> wrote:

> Hi all,
>
> I use exeption handling quite frequently even in inner loops. A common
> pattern:
>
> let some_function ... =
> ...
> if cannot_compute then raise Not_found else value
>
> try
> let value = some_function ... in
> ...
> with Not_found ->
> handle_exception
>
> I use this pattern even if the direct caller of "some_function" handles
> the exception. In many cases I could design "some_function" in a way
> that it returns an optional value and check the optional value in the
> caller. Is this significantly (at least 10%) faster? If not, I would
> stay with my present design. However I am pressed for performance in the
> inner loops (I am only interested in compilation to native).
>
> Is there any information available on the preformance penalty of
> exception handling? Any hints? Thanks in advance.
>
> Regards
> Helmut
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
>

Re: [Caml-list] Performance penalty of exception handling

[David Rajchenbach-Teller]

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

I did some benchmarking a while ago.
You can find the summary here:
https://hal.inria.fr/inria-00432575/PDF/monad.pdf

Cheers,
 David



On 16/09/15 21:08, Helmut Brandl wrote:
> Hi all,
> 
> I use exeption handling quite frequently even in inner loops. A common
> pattern:
> 
>     let some_function ... =
>             ...
>            if cannot_compute then raise Not_found else value
> 
>     try
>         let value = some_function ... in
>         ...
>     with Not_found ->
>        handle_exception
> 
> I use this pattern even if the direct caller of "some_function" handles
> the exception. In many cases I could design "some_function" in a way
> that it returns an optional value and check the optional value in the
> caller. Is this significantly (at least 10%) faster? If not, I would
> stay with my present design. However I am pressed for performance in the
> inner loops (I am only interested in compilation to native).
> 
> Is there any information available on the preformance penalty of
> exception handling? Any hints? Thanks in advance.
> 
> Regards
> Helmut
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Caml-list] Performance penalty of exception handling

[Milan Stanojević]

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

(correctly sending to the list)

> > Optional values often require allocation (and, therefore, garbage
collection). Unless your process is so short-lived that the garbage
collector never runs, exceptions are going to be faster. So, if you
benchmark this, make sure your benchmarks run for a while.
> >
> > Someone who knows the compiler better than I will be able to tell you
if (Some x) when immediately pattern-matched across a function call causes
an allocation.
> >
> > Constant exception constructors like Not_found, I believe, require no
allocation in recent versions of OCaml.
> >
>

The cost of an exception is not just its allocation. You also need to setup
the exception handler. Also, backtrace recording is not cheap, so one
should use raise_notrace primitive for cases like this.

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

Re: [Caml-list] Performance penalty of exception handling

[John Whitington]

Hi,

Helmut Brandl wrote:
> I use exeption handling quite frequently even in inner loops. A common
> pattern:
>
> let some_function ... =
> ...
> if cannot_compute then raise Not_found else value
>
> try
> let value = some_function ... in
> ...
> with Not_found ->
> handle_exception
>
> I use this pattern even if the direct caller of "some_function" handles
> the exception. In many cases I could design "some_function" in a way
> that it returns an optional value and check the optional value in the
> caller. Is this significantly (at least 10%) faster?

Optional values often require allocation (and, therefore, garbage 
collection). Unless your process is so short-lived that the garbage 
collector never runs, exceptions are going to be faster. So, if you 
benchmark this, make sure your benchmarks run for a while.

Someone who knows the compiler better than I will be able to tell you if 
(Some x) when immediately pattern-matched across a function call causes 
an allocation.

Constant exception constructors like Not_found, I believe, require no 
allocation in recent versions of OCaml.

Cheers,

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/

[Caml-list] Performance penalty of exception handling

[Helmut Brandl]

Hi all,

I use exeption handling quite frequently even in inner loops. A common 
pattern:

     let some_function ... =
             ...
            if cannot_compute then raise Not_found else value

     try
         let value = some_function ... in
         ...
     with Not_found ->
        handle_exception

I use this pattern even if the direct caller of "some_function" handles 
the exception. In many cases I could design "some_function" in a way 
that it returns an optional value and check the optional value in the 
caller. Is this significantly (at least 10%) faster? If not, I would 
stay with my present design. However I am pressed for performance in the 
inner loops (I am only interested in compilation to native).

Is there any information available on the preformance penalty of 
exception handling? Any hints? Thanks in advance.

Regards
Helmut