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 080A7820A1 for ; Fri, 6 Sep 2013 20:45:53 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of martin.jambon@ens-lyon.org) identity=pra; client-ip=66.111.4.27; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of martin.jambon@ens-lyon.org does not assert whether or not 66.111.4.27 is permitted sender) identity=mailfrom; client-ip=66.111.4.27; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@out3-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.27; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="postmaster@out3-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYBAM0hKlJCbwQblGdsb2JhbABbxWmBJhYOAQEBAQcNCQkUBCSCJAEBBAE4CDgCDwsYCRYPCQMCAQIBRRMIAQGHeAarT4RQjVEGkAOEHYk4lGyOeg X-IPAS-Result: AmYBAM0hKlJCbwQblGdsb2JhbABbxWmBJhYOAQEBAQcNCQkUBCSCJAEBBAE4CDgCDwsYCRYPCQMCAQIBRRMIAQGHeAarT4RQjVEGkAOEHYk4lGyOeg X-IronPort-AV: E=Sophos;i="4.90,856,1371074400"; d="scan'208";a="31847564" Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 06 Sep 2013 20:45:51 +0200 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7381121014 for ; Fri, 6 Sep 2013 14:45:50 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 06 Sep 2013 14:45:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=VDhIb/yYyiU161vJDmiQoH B5bBs=; b=ilu1gVDEVsgc+EZ5jNNtkrvi1eBrCDk+76t23sJibjd6nCT10IQG// +mBK/tearVhv28VfN0MaFDH0cCPQhE8J3HVTL5qPUIOP06PaUqRZUDykzCDLbdku unPoKLtd1oKqktWYiAiJjFHvrB4AJbnQMg+Ej4PTFOvgu8WHqbXqA= X-Sasl-enc: s0mmwCrTivuB5oYD+z+isMfyCmR1uz6j7WzaPJoDrngv 1378493150 Received: from [192.168.2.6] (unknown [50.193.45.145]) by mail.messagingengine.com (Postfix) with ESMTPA id 197D0C00E88 for ; Fri, 6 Sep 2013 14:45:50 -0400 (EDT) Message-ID: <522A22DC.9080604@ens-lyon.org> Date: Fri, 06 Sep 2013 11:45:48 -0700 From: Martin Jambon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: caml-list@inria.fr References: <5229DEF9.7040706@inria.fr> In-Reply-To: <5229DEF9.7040706@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Accelerating compilation 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. Things that have resulted for in significant speed improvements in the recent past (< 2 years): 1. using omake instead of ocamlbuild 2. bytecode camlp4 preprocessing < native camlp4 < camlp5 < nothing 3. building only one executable I don't have much information on ocamlbuild other than I couldn't make it perform as expected (and I don't like the idea of having to write build instruction in OCaml anyway). I know that omake does what one would expect in terms on parallelism and caching. Point (2) is easily checked with 'top'. On my machine using an external SSD, what takes the most time is IOs at linking time when using a good number of libraries. I don't know if it's preventable, if it's a bad interaction between ocamlfind and the compilers, or something else. What I do now is build everything into a single executable with subcommands, which is handy anyway so why not. > It does help to prevent useless recompilation, but > what good does it make to prevent a useless recompilation once in a > while if it is at the cost of losing a lot of time in all other cases? > I'm sure it is project-dependent though so it should only be an option, > say, -do-not-hash, or -comparison-mode dateandsize. > > 3) Parallel compilation in Ocamlbuild > > Of course it would help but it is not easy to implement so I'm just > putting it there to be exhaustive. > > I think the most important point is the first one, as the other two > depend on the build system, and they have been debated already. I'm not > aware of any discussion about separing typing and code generation > though. What do you think about that? > > Cheers, >