English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Module (re)construction cost
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-07-27 (13:25)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] Module (re)construction cost
> Does building a functorized module cost anything at all ?

There is one overhead, which affects mostly ocamlopt.  Functions in
the functor body are compiled without knowledge of the functor
argument, and hence will use the generic, unoptimized calling protocol
to invoke functions from the functor parameter.  Consider:

module F(X : sig val f : int -> int end) =
    let g x = ... f x ...

module A = struct let f x = ... end

module B = F(A)

let _ = B.g 3

Calls from B.g to A.f will be unoptimized (no inlining, no special
entry point for curried or tupled functions).  However, the call to
B.g is optimized as usual.  

In contrast, consider the same code without functors:

module A = struct let f x = ... end

module B = struct let g x = ... A.f x ... end

Here, the call from B.g to A.f is optimized.

> i.e. does functor
> application cost anything (time ? memory ?).

Evaluating the functor application itself is very cheap, it just
builds a tuple of values from a tuple of values.  Moreover, this takes
place at program start-up time, i.e. not often.  The main hidden cost
is the lack of optimization in certain function calls as described

- Xavier Leroy
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr