From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 637A47F736 for ; Wed, 16 Sep 2015 21:26:49 +0200 (CEST) IronPort-PHdr: 9a23:X1uIwBeQ8ppGSo1D/OVnOnrelGMj4u6mDksu8pMizoh2WeGdxc++YB7h7PlgxGXEQZ/co6odzbGG7+a6CCdZusbJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbvip9uJMk4R32r1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3MRLkjVbFTEBghNmk04oWr6UiCHkOz4S5IUmgSlwdURQLf5Rf2Wr/+tzu8sOdhjm3Sacb/SLRxXTW5849qTgXpgWEJLWhqymzPjt1Mi/cRhRu7pFRWz4fRe8vdYP93ZKD1ZckdQmQEQstaVypGBoSzboYUSeEGOLALgZP6og5EiBKkBkGFCOrq0XUA0nr/x64Sy/4mFg+DwAErH9QJtHPbrdjucqwVVLbmn+Hz0TzfYqYOin/G44/Sf0V98Pw= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=mark@proof-technologies.com; spf=Pass smtp.mailfrom=mark@proof-technologies.com; spf=Pass smtp.helo=postmaster@smtp.hosts.co.uk Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mark@proof-technologies.com) identity=pra; client-ip=85.233.160.19; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mark@proof-technologies.com"; x-sender="mark@proof-technologies.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mark@proof-technologies.com designates 85.233.160.19 as permitted sender) identity=mailfrom; client-ip=85.233.160.19; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mark@proof-technologies.com"; x-sender="mark@proof-technologies.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@smtp.hosts.co.uk designates 85.233.160.19 as permitted sender) identity=helo; client-ip=85.233.160.19; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mark@proof-technologies.com"; x-sender="postmaster@smtp.hosts.co.uk"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CAIAC2wflVmxOg6VVeg3dpmV6EAgiOYZJwh0M8EAEBAQEBAQEBEAEBAQEBBgsLCSEugh2CCAQkBEcQFhoCCR0CPgQFGAESEogHAwoMAQi1RoZYiQUDhF4MIIEiik6CUIUtgUMFhXwMjC6DKAGBGoN1h3SBTUaGXRCOJYNsOIQtPTOKKgEBAQ X-IPAS-Result: A0CAIAC2wflVmxOg6VVeg3dpmV6EAgiOYZJwh0M8EAEBAQEBAQEBEAEBAQEBBgsLCSEugh2CCAQkBEcQFhoCCR0CPgQFGAESEogHAwoMAQi1RoZYiQUDhF4MIIEiik6CUIUtgUMFhXwMjC6DKAGBGoN1h3SBTUaGXRCOJYNsOIQtPTOKKgEBAQ X-IronPort-AV: E=Sophos;i="5.17,541,1437429600"; d="scan'208";a="147515525" Received: from smtp.hosts.co.uk ([85.233.160.19]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Sep 2015 21:26:48 +0200 Received: from [192.168.0.127] (helo=bigears.namesco.net) by smtp.hosts.co.uk with esmtps (UNKNOWN:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.80.1) (envelope-from ) id 1ZcILv-0002fk-CB; Wed, 16 Sep 2015 20:26:47 +0100 Received: from webmail by bigears.namesco.net with local (Exim 4.72) (envelope-from ) id 1ZcILv-0002DW-53; Wed, 16 Sep 2015 20:26:47 +0100 To: , From: =?utf-8?q?=22Mark=20Adams=22?= Reply-To: =?utf-8?q?=22Mark=20Adams=22?= MIME-Version: 1.0 X-Mailer: Namesco Webmail v3.0 Message-ID: <1442431607294@names.co.uk> Date: Wed, 16 Sep 2015 20:26:47 +0100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Performance penalty of exception handling 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 wrote: > Hi all, > > I use exeption handling quite frequently even in inner loops. A common > pattern: > > let some_function ... =3D > ... > if cannot_compute then raise Not_found else value > > try > let value =3D 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 > > >