Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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


  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