From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2B8eD8u024014 for ; Sun, 11 Mar 2012 09:40:13 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApECAJxjXE/RVdK2kmdsb2JhbABBtTkIIgEBAQEJCwsHEimCCQEBAQQSAiwBGx0BAwwGBQsNLiEBAREBBQEcBhMeBIdonTYKi3iCcYQbP4h0AQULiTmHPQSVTIsrgxo9hAU X-IronPort-AV: E=Sophos;i="4.73,566,1325458800"; d="scan'208";a="135436058" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Mar 2012 09:40:09 +0100 Received: by iahk25 with SMTP id k25so7775306iah.27 for ; Sun, 11 Mar 2012 00:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5xHo4NYApdY9VuFRNvoJcH+FbKVFFVgFtLSze2oE7Ok=; b=B/tICO2lNCjqsPQn+OgoGXfjLRyQtOkP9spEXqzVSwEWXxcvMawMH6BkY1+fJxWCBu fZPpserU09yhVYxTQKM4/vvz5/YkokIL9zJu0/rg15IhTdXEzKZA0oAHYl6mnKlXsrUJ yowY2WCF9luDzNDxkXIfnZcXsHzEPlcdXg9QvqkZVz8k5f0VZBWlgTpXD5+InpYe8hIq 4iM6ncjBz8kmP78uFhcy1QklxNYpy/4aoCJsb9q2FTfHlXA4hJDRCM0Kc+auuaSYurMY ZD+V2WEDQ2a3cQwIf6LWo265zDD/K25XtiovxFuxo1zas5uFXu+vkrHYj0PTEQARkN8D i+UA== Received: by 10.42.180.66 with SMTP id bt2mr7626485icb.56.1331455208204; Sun, 11 Mar 2012 00:40:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.3.38 with HTTP; Sun, 11 Mar 2012 00:39:28 -0800 (PST) In-Reply-To: References: From: Gabriel Scherer Date: Sun, 11 Mar 2012 09:39:28 +0100 Message-ID: To: SerP Cc: caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2B8eD8u024014 Subject: Re: [Caml-list] Very slow compilation I can't comment on the type-checker internals, but a general first step would be to make sure that you don't recompile things that you don't need to. If you change the *implementation* of a module without changing its interface, you should not have to recompile any other module, at least when using bytecode compilation. You need not recompile even the modules that depend on this -- there is only an interface-dependency. With native compilation, the compiler can inspect depending modules to perform some cross-module optimizations, so there will be an implementation-dependency by default, but you can disable it -- the .cmx for bar.ml won't depend on its dependency foo.ml if foo.cmx is not available at compile time. It's simpler to just use ocamlc for development. It's also faster at code generation, but apparently your bottleneck is typing. To fully benefit from separate compilation, you may want to have a slightly more fine-grained separation of you program into compilation units. If a given module interface can be split in two parts, one that evolves slowly and on which a lot of modules depend, and one that is little used outside but changes frequently, it's a big win to split it into two separate module interfaces -- when you can, eg. the whole thing is not encapsulated as a functor. On Sun, Mar 11, 2012 at 9:11 AM, SerP wrote: > We encountered a problem of a slow compilation. When the project grew up, > the time of compilation increased considerably. We have many classes and > objects, and the type checking of objects and classes performs very slowly. > I have Core i3 3GHz iMac, and the average compilation time of one module is > 7-13 seconds. The entire projet is compiled within 10-15 minutes. The major > part of the time is taken by "Typemod.type_implementation", which include > many calls of Ctype.unify (80% of compilation time). Now, it is getting hard > and slow to develop the projetct, are there any ways to accelarate it? It is > difficult to get all fine points, but I wish I could make the process > faster. Thanks for any help or comments. Looking forward to your reply