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 0CD93820A1 for ; Mon, 9 Sep 2013 10:36:58 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.176 as permitted sender) identity=mailfrom; client-ip=134.160.33.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.176 as permitted sender) identity=helo; client-ip=134.160.33.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4CAHmHLVKGoCGwh2dsb2JhbABbwzCCdYEzDgEBAQoLCQcWKIIlAQEFMgEFQBELGAkWDwkDAgECAUUTCAEBh37FIJAHFoQHA4kzjkKGLI5p X-IPAS-Result: Ao4CAHmHLVKGoCGwh2dsb2JhbABbwzCCdYEzDgEBAQoLCQcWKIIlAQEFMgEFQBELGAkWDwkDAgECAUUTCAEBh37FIJAHFoQHA4kzjkKGLI5p X-IronPort-AV: E=Sophos;i="4.90,866,1371074400"; d="scan'208";a="32046325" Received: from postman4.riken.jp (HELO postman.riken.jp) ([134.160.33.176]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Sep 2013 10:36:56 +0200 Received: from postman.riken.jp (postman4.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 154668280E4 for ; Mon, 9 Sep 2013 17:36:54 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 6A8E47F803F for ; Mon, 9 Sep 2013 17:36:53 +0900 (JST) Message-ID: <522D88A4.4080106@riken.jp> Date: Mon, 09 Sep 2013 17:36:52 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: caml-list@inria.fr References: <5229DEF9.7040706@inria.fr> <522A22DC.9080604@ens-lyon.org> <522D838B.8050203@inria.fr> In-Reply-To: <522D838B.8050203@inria.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.9.82715 Subject: Re: [Caml-list] Accelerating compilation On 09/09/2013 05:15 PM, Romain Bardou wrote: > Le 06/09/2013 20:45, Martin Jambon a écrit : >> On 09/06/2013 06:56 AM, Romain Bardou wrote: >>> Hello list, >>> >>> As my project grows bigger, it is becoming much less efficient to use >>> the type-checker to quickly find places in my code which must be updated >>> (e.g. pattern-matching). Here is a wishlist for improvements. >>> >>> 1) Separate typing and code generation, in ocamlc and in ocamlopt >>> >>> For instance, provide an option -typing-only which would mean "only >>> produce the .cmi but do not produce the .cmo or the .cmx". The compiler >>> would only need the .cmi of the dependencies, not their .cmo or .cmx. >>> This would make it possible to have a Makefile target, or an Ocamlbuild >>> option, to just type. >>> >>> Also, provide an option -do-not-retype which would mean "if the .cmi >>> exists, load it instead of type-checking again". This would allow the >>> build process to first type-check (using -typing-only) and then generate >>> the code without type-checking again (using -do-not-retype). Of course >>> the build system should be very careful to ensure the .cmi is >>> up-to-date. This option could also help when compiling both in bytecode >>> and in native code. This option is not necessary to just find errors >>> quickly, though. >>> >>> 2) Be able to disable Ocamlbuild's digest mechanism and use dates and >>> file sizes instead >>> >>> If I am not mistaken, this is one of the main reasons why Ocamlbuild is >>> slower that make. >> >> It would be interesting to know the size of your project and the time it >> takes to build it. > > There are about 30K lines of code in the core of the project, which is > well-split in a rather large number of files (Ocamlbuild reports about > 400 targets). It takes about 30s to compile in native mode using the > native compilers. > > It might seem very small compared to say, Coq :) But still, having to > wait ~10s just to find the next pattern-matching to fix is already > annoying and it will only get worse. Isn't the merlin tool able to do that: show compilation errors as you type? I don't use merlin that much but thought it was.