From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA18295 for caml-redistribution; Wed, 13 Oct 1999 08:52:34 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA12269 for ; Tue, 12 Oct 1999 17:04:03 +0200 (MET DST) Received: from tobago.inria.fr (tobago.inria.fr [128.93.8.21]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA16008 for ; Tue, 12 Oct 1999 17:04:02 +0200 (MET DST) Received: (from doligez@localhost) by tobago.inria.fr (8.6.10/8.6.6) id RAA19904 for caml-list@pauillac.inria.fr; Tue, 12 Oct 1999 17:04:02 +0200 Date: Tue, 12 Oct 1999 17:04:02 +0200 From: Damien Doligez Message-Id: <199910121504.RAA19904@tobago.inria.fr> To: caml-list@pauillac.inria.fr Subject: Re: About array Sender: weis >From: Anton Moscal >Evaluation `f i' can cause GC call -> we must use modify function. Really >we can check address of our fresh array after each `f i'. While this >address remains unchanged we have no need to call `modify'. I think this >will be good. Wrong. There is no guarantee that the GC will move your fresh array. In most cases it will not because the array will already be in the major heap. >I made the following experiment: [replacing Array.init with a home-brewed version] >time became 0.97 sec (but this version will not work >with float arrays) Indeed, it only works with int arrays. And the only reason it's faster is because it's monomorphic. All your GC-oriented "magic" amounts to nothing (you're not avoiding the call to "modify"). In fact, with this "init" function is even faster: let init l (f : int -> int) = if l = 0 then [||] else let res = create l (f 0) in for i = 1 to pred l do unsafe_set res i (f i) done; res ;; (i.e. the standard library's "init" with a type constraint) -- Damien