caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] lazy vs function for values that are used once at most
@ 2004-06-30 13:31 henri dubois-ferriere
  2004-06-30 13:39 ` Jon Harrop
  0 siblings, 1 reply; 4+ messages in thread
From: henri dubois-ferriere @ 2004-06-30 13:31 UTC (permalink / raw)
  To: Ocaml

hi, 

when one has a value v that is going to be either used 0 or 1 time, is
there any difference in terms of overhead (ie for building the
closure,  GC performance, etc) between passing around  (lazy v) and
then forcing the value if needed, or passing around (fun () -> v) and
evaluating f when needed?

i would guess these are equivalent overhead-wise but maybe there's
more to it than meets the eye.

thanks
henri

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] lazy vs function for values that are used once at most
  2004-06-30 13:31 [Caml-list] lazy vs function for values that are used once at most henri dubois-ferriere
@ 2004-06-30 13:39 ` Jon Harrop
  2004-06-30 14:21   ` henri dubois-ferriere
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Harrop @ 2004-06-30 13:39 UTC (permalink / raw)
  To: Ocaml


> when one has a value v that is going to be either used 0 or 1 time, is
> there any difference in terms of overhead (ie for building the
> closure,  GC performance, etc) between passing around  (lazy v) and
> then forcing the value if needed, or passing around (fun () -> v) and
> evaluating f when needed?

IIRC, Lazy is slower because of the (wasted, in this case) overhead of 
memoizing the result.

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] lazy vs function for values that are used once at most
  2004-06-30 13:39 ` Jon Harrop
@ 2004-06-30 14:21   ` henri dubois-ferriere
  2004-06-30 14:44     ` Frederic van der Plancke
  0 siblings, 1 reply; 4+ messages in thread
From: henri dubois-ferriere @ 2004-06-30 14:21 UTC (permalink / raw)
  To: Jon Harrop; +Cc: Ocaml

ok.
actually, i should refine my question a little further:
in the vast majority of cases, the value is *not* used at all.
so i suppose the memoization overhead you mention does not occur when
a lazy value is not forced.

so, the question then becomes:

any difference in overhead between creating 
(lazy v)
and 
(fun () -> v)

?
thanks for any insights
henri







On Wed, 30 Jun 2004 14:39:15 +0100, Jon Harrop
<postmaster@jdh30.plus.com> wrote:
> 
> > when one has a value v that is going to be either used 0 or 1 time, is
> > there any difference in terms of overhead (ie for building the
> > closure,  GC performance, etc) between passing around  (lazy v) and
> > then forcing the value if needed, or passing around (fun () -> v) and
> > evaluating f when needed?
> 
> IIRC, Lazy is slower because of the (wasted, in this case) overhead of
> memoizing the result.
> 
> Cheers,
> Jon.
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] lazy vs function for values that are used once at most
  2004-06-30 14:21   ` henri dubois-ferriere
@ 2004-06-30 14:44     ` Frederic van der Plancke
  0 siblings, 0 replies; 4+ messages in thread
From: Frederic van der Plancke @ 2004-06-30 14:44 UTC (permalink / raw)
  To: Ocaml

henri dubois-ferriere wrote:
> 
> ok.
> actually, i should refine my question a little further:
> in the vast majority of cases, the value is *not* used at all.
> so i suppose the memoization overhead you mention does not occur when
> a lazy value is not forced.
> 
> so, the question then becomes:
> 
> any difference in overhead between creating
> (lazy v)
> and
> (fun () -> v)
> 
> ?
> thanks for any insights
> henri

Sure. The value (lazy ...) is something significantly more complex than (fun () ->
...) and contains a (fun () -> ...) internally anyway. So it has overhead.

See the source (lazy.ml) if you want to be sure and precise. For instance (lazy 33)
has type (int Lazy.t) where Lazy.t is defined as such:

type 'a status =
  | Delayed of (unit -> 'a)
  | Value of 'a
  | Exception of exn
;;

type 'a t = 'a status ref;;

So before computation is forced, (lazy 33) = ref (Delayed (fun () -> 33)) which means
2 levels of indirection more -> somewhat slower access, 2 words of memory waste, more
strain on the GC.

Frédéric.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-06-30 14:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-30 13:31 [Caml-list] lazy vs function for values that are used once at most henri dubois-ferriere
2004-06-30 13:39 ` Jon Harrop
2004-06-30 14:21   ` henri dubois-ferriere
2004-06-30 14:44     ` Frederic van der Plancke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).