From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA02836; Fri, 28 May 2004 18:47:18 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 SAA31990 for ; Fri, 28 May 2004 18:47:17 +0200 (MET DST) Received: from cgpsrv2.cis.mcmaster.ca (univmail.CIS.McMaster.CA [130.113.64.46]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4SGlESH009066 for ; Fri, 28 May 2004 18:47:15 +0200 Received: from [130.113.68.27] (account carette@univmail.cis.mcmaster.ca HELO pccarettej) by cgpsrv2.cis.mcmaster.ca (CommuniGate Pro SMTP 4.1.8) with ESMTP id 43180163; Fri, 28 May 2004 12:47:12 -0400 Reply-To: From: "Jacques Carette" To: "'Richard Jones'" , Subject: RE: [Caml-list] Out_of_memory exception in output_value Date: Fri, 28 May 2004 12:47:20 -0400 Organization: McMaster University Message-ID: <003701c444d3$7163a340$1b447182@cas.mcmaster.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040528143134.GA12481@redhat.com> X-Miltered: at concorde with ID 40B76D12.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; jacques:01 caml-list:01 allocates:01 marshalled:01 doubles:01 jacques:01 ocaml:01 penalty:02 exception:02 failing:02 failing:02 data:03 seems:05 output:05 output:05 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > It turns out that during output_value, the OCaml code allocates a > block of memory to contain the marshalled representation of the data. > Each time it runs out of room, it doubles the size of that block using > realloc(). Wouldn't it be more system-friendly to try successively factors *2, *1.5, *1.1, and *1.05 before actually failing? This would not cost any performance penalty in successful cases, and could decrease the number of failing cases. Seems win-win to me. And as long as it is a multiplicative factor, this does not lead to algorithmic degenerescence. Jacques ------------------- 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