From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 11061BC57 for ; Fri, 19 Nov 2010 15:54:40 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFAOod5kyty1O7/2dsb2JhbACUWo4Ccb1EhUsEhFqJDxo X-IronPort-AV: E=Sophos;i="4.59,223,1288566000"; d="scan'208";a="79664284" Received: from elehack.net ([173.203.83.187]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 Nov 2010 15:54:39 +0100 Received: from [192.168.42.103] (unknown [68.168.162.166]) by elehack.net (Postfix) with ESMTPSA id F2AB6C89B9 for ; Fri, 19 Nov 2010 08:54:41 -0600 (CST) Message-ID: <4CE68FAB.6020102@elehack.net> Date: Fri, 19 Nov 2010 08:54:35 -0600 From: Michael Ekstrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Optimizing garbage collection References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; eray:01 ozkural:01 ocaml:01 ocaml:01 libref:01 blog:98 blog:98 garbage:01 garbage:01 wrote:01 wrote:01 heap:01 heap:01 caml-list:01 minor:01 On 11/18/2010 09:51 AM, Eray Ozkural wrote: > A program I wrote constructs a lot of small lists, and strings and > discards them. It's a search algorithm. I profiled this code and saw > that garbage collection takes significant time. > > In C++, we can write custom allocators to optimize the data structures > that cause such slowdowns. Any recommended strategies in ocaml? The OCaml garbage collector exposes a variety of tuning parameters through the Gc module[1] and the OCAMLRUNPARAM environment variable[2]. I would tweak those. In particular, I would recommend increasing the minor heap size so that more of your data can be quickly discarded. You can also increase the space overhead, thereby causing the GC to be less aggressive at the expense of higher memory usage/more waste. Lastly, I often increase the heap increment to allow memory to allow the heap to expand more quickly, but I do not know if that will help in your case or not. I have documented my practices more thoroughly at my blog[3]. As I see it, the biggest gains will be by tuning your code and your minor heap size so that ephemeral structures never hit the major heap. My rule of thumb is that one "work unit", if you have such a concept, should fit in the minor heap. Collecting dead structures from the minor heap is fast; moving a structure to the major heap only to have it be unreachable by the next GC cycle can cause substantial GC thrashing. You're on to a good start, though, by measuring. I use gprof heavily as I tweak my code's performance. - Michael 1. http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html 2. http://caml.inria.fr/pub/docs/manual-ocaml/manual024.html#toc96 3. http://elehack.net/michael/blog/2010/06/ocaml-memory-tuning