From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: SerP <serp256@gmail.com>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Very slow compilation
Date: Sun, 11 Mar 2012 09:39:28 +0100 [thread overview]
Message-ID: <CAPFanBHsBUkAh8-rJJdC=uv9pXnef7duxQ-gHL0FOtvceuwTPQ@mail.gmail.com> (raw)
In-Reply-To: <CAHgca+_m7iw8iFDb+23m3UgWMFM5j__ctY3o1oTyJ-HKP_57yQ@mail.gmail.com>
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 <serp256@gmail.com> 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
next prev parent reply other threads:[~2012-03-11 8:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-11 8:11 SerP
2012-03-11 8:39 ` Gabriel Scherer [this message]
2012-03-11 9:04 ` Adrien
2012-03-11 9:21 ` Raphael Proust
2012-03-13 22:02 ` Matti Jokinen
2012-03-13 22:46 ` Gerd Stolpmann
2012-03-14 5:33 ` Gabriel Scherer
2012-03-14 8:52 ` Pierre Chambart
2012-03-13 16:58 ` Richard W.M. Jones
2012-03-14 14:45 tools
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPFanBHsBUkAh8-rJJdC=uv9pXnef7duxQ-gHL0FOtvceuwTPQ@mail.gmail.com' \
--to=gabriel.scherer@gmail.com \
--cc=caml-list@inria.fr \
--cc=serp256@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox