[Caml-list] Module (re)construction cost

[Caml-list] Module (re)construction cost

[Berke Durak]

Does building a functorized module cost anything at all ? I have a
program with a lot of high-level modules that depend on a small set of
interdependent modules parametrized by one common module. Should the
high-level modules get the (already-built) core modules as
``parameters'' from the main module, or should they reconstruct them
by getting only the common module from their parent ? i.e. does functor
application cost anything (time ? memory ?).
--
Berke
-------------------
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

Re: [Caml-list] Module (re)construction cost

[Xavier Leroy]

> 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) =
  struct
    let g x = ... f x ...
  end

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
above.

- 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

Re: [Caml-list] Module (re)construction cost

[Markus Mottl]

On Fri, 27 Jul 2001, Xavier Leroy wrote:
> > 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
> above.

Unless this functor application is used to create a local module, of
course. Then each call to the enclosing function (and if control flow
actually reaches the functor application) will require the creation of
this tuple.

It should also be noted that this may mean evaluating possibly expensive
expressions whose values will be put into the tuple slots. In fact,
you could even have expressions there that do not terminate at all
or eat up all your memory depending on the parameters passed via the
functor parameter. E.g.:

  module type VICE = sig
    val sleep : bool
    val munch : bool
  end

  module Make (Vice : VICE) = struct
    let _ =
      if Vice.munch then
        let stomach = ref [] in
        for i = 1 to 10000000 do
          stomach := () :: !stomach
        done;
      if Vice.sleep then while true do () done
  end

  let sin sleep munch =
    let module Immoderateness = struct
      let munch = munch
      let sleep = sleep
    end in
    let module Cockaigne = Make (Immoderateness) in
    ()

  let _ = sin true true

First the functor application will eat a good share of your memory. Then
it will put your machine to sleep forever...

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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

Re: [Caml-list] Module (re)construction cost

[William Chesters]

Markus Mottl writes:
 >   let sin sleep munch =
 >     let module Immoderateness = struct
 >       let munch = munch
 >       let sleep = sleep
 >     end in
 >     let module Cockaigne = Make (Immoderateness) in
 >     ()
 > 
 >   let _ = sin true true

Never mind IFP.  If there's a competition for computer poetry, Markus
is going to win :).
-------------------
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