From: Raphael Proust <raphlalou@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 10:21:40 +0100 [thread overview]
Message-ID: <CAAmHUA=m1Vtiksi7LTEaGHG2NiDZpwsWRb+UTdQL+Ne5-Eg98Q@mail.gmail.com> (raw)
In-Reply-To: <CAPFanBHsBUkAh8-rJJdC=uv9pXnef7duxQ-gHL0FOtvceuwTPQ@mail.gmail.com>
When working with ocamlduce (a few years ago) the same problem was
raised. A simple thing that can greatly reduce typing time is putting
explicit type annotations. Although the verbosity is increased it is
not that much of a burden if the annotated parts do not evolve too
much.
The same probably applies with plain ocaml. (It might be that
objects/classes typing is more complicated due to sub-typing, although
someone with insider knowledge would know better.)
On Sun, Mar 11, 2012 at 9:39 AM, Gabriel Scherer
<gabriel.scherer@gmail.com> wrote:
> 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
>
>
> --
> Caml-list mailing list. Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
--
_______
Raphael
next prev parent reply other threads:[~2012-03-11 9:21 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
2012-03-11 9:04 ` Adrien
2012-03-11 9:21 ` Raphael Proust [this message]
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='CAAmHUA=m1Vtiksi7LTEaGHG2NiDZpwsWRb+UTdQL+Ne5-Eg98Q@mail.gmail.com' \
--to=raphlalou@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