From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 547397EC6E for ; Fri, 17 Jan 2014 10:22:31 +0100 (CET) Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4BAJFf2FKBaB4inGdsb2JhbABZhxe5IhYOAQEBAQEIFAk8giUBAQEDASMEUgULCyEhAgIPBUmIDwipJJwdF5F1gUkEmCCVRg X-IPAS-Result: Ap4BAJFf2FKBaB4inGdsb2JhbABZhxe5IhYOAQEBAQEIFAk8giUBAQEDASMEUgULCyEhAgIPBUmIDwipJJwdF5F1gUkEmCCVRg X-IronPort-AV: E=Sophos;i="4.95,670,1384297200"; d="scan'208";a="53666628" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 17 Jan 2014 10:22:31 +0100 Received: from emmental.inria.fr (emmental.inria.fr [128.93.0.14]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 32A3D1409132A; Fri, 17 Jan 2014 10:22:30 +0100 (CET) Date: Fri, 17 Jan 2014 10:22:29 +0100 From: Simon Cruanes To: Gabriel Scherer Cc: David House , Julien Blond , Damien Guichard , Caml Mailing List Message-ID: <20140117092229.GI11251@emmental.inria.fr> References: <523666417617602473@orange.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1MV0VfA6Y2yiVCnw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Jan 17 10:22:30 2014 +0100 (CET)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000000, queueID=538BF1409132C X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: Re: [Caml-list] How much optimized is the 'a option type ? --1MV0VfA6Y2yiVCnw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Fri, 17 Jan 2014, Gabriel Scherer a =C3=A9crit : > There have been recurrent discussions of optimizing `'a option` to > avoid allocation in some cases, which is interesting when it is used > as a default value for example. (The nice recent blog post by Thomas > Leonard also seems to assume that `'a option` is somehow optimized.) >=20 > My strictly personal opinion is that I doubt this would be a good > idea, because I expect a fair share of the programming practice that > currently use ('a option) to move to something like (('a, > error-description) either) later in their lifetime, and I wouldn't > want people to avoid to do that for performance concerns. > Historically, we've rather come to see special-case representation > optimizations (eg. array of floats) as a mistake -- but on the other > hand there is not much downside to record of floats. I think optimization of some local uses of options, such as: let rec iter_stream f s =3D match (try Some (MyStream.get s) with End_of_stream -> None) with | None -> () | Some (x, s') -> f x; iter_stream f s' where an option is used to keep the function tail-rec (I've heard several people tell me they often need to use this), or other cases like optional parameters (which are not going to move to Either), would be useful and future-proof. I hope the current work on optimizations will help with this kind of cases (removing useless allocations of local options, references, exceptions when no escape is possible). > --=20 Simon --1MV0VfA6Y2yiVCnw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJS2PZUAAoJEErAHQhJqmK2ugMP/31bbOt1GTDdr81XKOZBJGQI PeAmAo5ZZKf8rGIll8gmw89U3zRfHXQVSzl2gaVbA/mz8btSZTxzrAk9c1iqWZ+D HA9BUllG4FBy1j/crX6RK7vkw0tqmlQ8vNp+Vlwa1bETHMgfP2jBoyCW73YzCnZB ZnPbrlLjefTQecl8ezAlZu1dZYbGlt3sm8mMKjA08tdq/72pSxDgmqUJGDaWUPh6 kES9YX9nt1k/vCluFTW/m0SjPbdcpogObLaGANzv+qxBa3gx5px6zEKRer7AUsmB ddABg5pGtyEgfeu+cuOtBRRaCjAOYvKbQxHIOyjRcmbkfVg5T1Bo29m2kIziItQi 7C0vrvf0fF7jmvIsva513XHXlZ9/CzfwKgDSCmBloeVD6S29jP1Ma8UcIniU7KLP GQSAz/HIpRbh0az7aJWXHDjENAS0I1laoz0RZCuYDAtlURAdNEraRYLQ4Q96gneE ovg63fx07tIZP3ks6e+93mxSBDWvB7YDOb8iVSj3HwwblAhb5ybx8X877IS3n8is GNEysIGuZSqdd7uS9PGpDUfHqf5S9/7LHpm6i2HPkRFyGbSY91ZXT1H12RVhWN1t 7yH0jX5aoVn1Z3DpIArjWo6MkvvCywUUZcPlJciCwnptVbrf8SdKMiW005yxlaeg g0Hd17X0D3+R0v8P9hL2 =PEKq -----END PGP SIGNATURE----- --1MV0VfA6Y2yiVCnw--