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 XAA02767; Thu, 10 Apr 2003 23:22:34 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA02771 for ; Thu, 10 Apr 2003 23:22:33 +0200 (MET DST) Received: from xanadu.ece.ucsb.edu (xanadu.ece.ucsb.edu [128.111.56.51]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h3ALMV924068 for ; Thu, 10 Apr 2003 23:22:32 +0200 (MET DST) Received: from ece.ucsb.edu (gimli.ece.ucsb.edu [128.111.56.252]) by xanadu.ece.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h3ALMUe24233 for ; Thu, 10 Apr 2003 14:22:30 -0700 (PDT) Date: Thu, 10 Apr 2003 14:21:47 -0700 Subject: Re: [Caml-list] Slow GC problem Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Shivkumar Chandrasekaran To: caml-list@inria.fr Content-Transfer-Encoding: 7bit In-Reply-To: <2E57564C-69AC-11D7-B7DE-0003930FCE12@inria.fr> Message-Id: <6FA5A4AF-6B9A-11D7-B23F-000393942C76@ece.ucsb.edu> X-Mailer: Apple Mail (2.552) X-Spam: no; 0.00; shivkumar:01 shiv:01 caml-list:01 re-use:01 bigarrays:01 allocating:01 malloc:01 gc'd:01 soundness:01 --shiv--:01 damien:01 solver:01 chunks:01 847:99 compactor:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I took Damien's advice (thanks) and spent some time trying to re-use all the bigarrays I was allocating. However, my bigarray use is spread out over a fairly complicated algorithm, and the only way to make a good dent on bigarray use would be to completely rewrite the algorithm in a more traditional fortran77 style. Which would of course mean that I would have to first figure out the entire memory usage pattern. ...... So I am pondering another solution: What if I modified bigarray_stubs.c to use the malloc and free calls of the Boehm gc (6.1-4) garbage collector? My reasoning is that malloc is performing poorly due to fragmentation, and switching to a gc'd version might help out. Before I try this I would like some feedback from the list on the soundness of this idea. Thanks, --shiv-- On Tuesday, April 8, 2003, at 03:23 AM, Damien Doligez wrote: >> I have a gc efficiency problem for which I require some advice. I >> have read both the O'Reilly book and the manual on gc. > [...] >> Below I give the gc stats just before and after the solver routine >> is called in the in-core solver: >> >> "Just before" "Just after" >> minor_words: 46243376 139259767 >> promoted_words: 928267 2595523 >> major_words: 2883087 39489766 >> minor_collections: 1412 4591 >> major_collections: 18 52 >> heap_words: 2150400 1044480 >> heap_chunks: 35 17 >> top_heap_words: 2150400 5038080 >> live_words: 1842373 840037 >> live_blocks: 253926 116816 >> free_words: 307180 204440 >> free_blocks: 47368 17 >> largest_free: 10928 61440 >> fragments: 847 3 >> compactions: 0 2 > > As others have said, this is not really enough information to tell > what is going on. What we can say from the above is: > > 1. You are allocating lots and lots of data structures in the major > heap (maybe finalized bigarray descriptors) > 2. The compactor was called twice, which may indicate that you have > a fragmentation problem. > 3. The compactor was called near the end of the solver routine, > which must have erased most of the evidence... > > -- Damien > --shiv-- ------------------- 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