From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 4977D7EE4B for ; Mon, 30 Sep 2013 13:19:40 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@dark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBAIldSVJZELGal2dsb2JhbABagz+tU5N8gT8OAQEBAQEIFgc8giUBAQQBeQULCxguVwYTiAAKCL0GBI8eMweDH4EDA5Qig12TX4E/Ow X-IPAS-Result: AqsBAIldSVJZELGal2dsb2JhbABagz+tU5N8gT8OAQEBAQEIFgc8giUBAQQBeQULCxguVwYTiAAKCL0GBI8eMweDH4EDA5Qig12TX4E/Ow X-IronPort-AV: E=Sophos;i="4.90,1007,1371074400"; d="scan'208";a="34891118" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail2-smtp-roc.national.inria.fr with SMTP; 30 Sep 2013 13:19:38 +0200 Received: (qmail 15949 invoked by uid 634); 30 Sep 2013 11:19:39 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from zone3.jesus.cam.ac.uk (HELO [192.168.22.175]) (131.111.243.143) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Mon, 30 Sep 2013 12:19:38 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) From: Anil Madhavapeddy In-Reply-To: <52495CE3.6050709@frisch.fr> Date: Mon, 30 Sep 2013 12:19:36 +0100 Cc: Fabrice Le Fessant , Francois Berenger , Ocaml Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <51C2EB73-2567-4A45-811B-5FB7C55C3D1A@recoil.org> References: <5229DEF9.7040706@inria.fr> <5229F284.5050806@inria.fr> <5249310F.7090108@riken.jp> <52495CE3.6050709@frisch.fr> To: Alain Frisch X-Mailer: Apple Mail (2.1811) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] from oasis to obuild (original subject was Re: Accelerating compilation) On 30 Sep 2013, at 12:13, Alain Frisch wrote: > On 9/30/2013 11:13 AM, Anil Madhavapeddy wrote: >> OASIS runs every single build command through ocamlfind. Moving that >> to the configure phase gives a big speedup for almost any project >> with a non-trivial number of source files. >=20 > Has someone investigated the overhead induced by ocamlfind? Is it about = the extra process, parsing the META files, or something else? >=20 > Since both ocamlfind and the compiler come in the form of a library (find= lib / compilerlib), it should not be too difficult to merge them into a si= ngle executable. If parsing the META files takes time, a cache mechanism i= n ocamlfind/findlib could help (maybe). Leo put together a compiler frontend that replaces the standard parsetree w= ith camlp4 that's statically linked: https://github.com/lpw25/ocaml-with-pp I'm currently untangling the precise camlp4 dependencies needed for a Core = build, so I can link a Core js_of_ocaml interactive toplevel for the Real W= orld OCaml website examples. Once that's done, I think linking in findlib = as a library and looking at performance is the next step, and then an inoti= fy/kqueue backend, and see how this all looks performance-wise... -anil (incidentally, figuring out the precise camlp4 modules and their loading or= der is a bit staggering, since camlp4 helpfully rewrites the command line f= lags to load further modules internally depending on the revised/original s= yntax dance. I'm looking forward to extension_points...)=