From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 469C4820A1 for ; Mon, 19 Aug 2013 08:43:57 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=74.125.83.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anthony.tavener@gmail.com designates 74.125.83.46 as permitted sender) identity=mailfrom; client-ip=74.125.83.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ee0-f46.google.com) identity=helo; client-ip=74.125.83.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-ee0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosCAGC9EVJKfVMulGdsb2JhbABbgzxRsFCGHIhGgRkIFg4BAQEBBw0JCRQEJIIlAQMCQAEbHQEDDAYFBAc7IgERAQUBHAYTh30BAw8MmEeMUIMCg2QKGScNZId0AQUMkFQHhBIDiS2ON4EtjkMWKYRhHQ X-IPAS-Result: AosCAGC9EVJKfVMulGdsb2JhbABbgzxRsFCGHIhGgRkIFg4BAQEBBw0JCRQEJIIlAQMCQAEbHQEDDAYFBAc7IgERAQUBHAYTh30BAw8MmEeMUIMCg2QKGScNZId0AQUMkFQHhBIDiS2ON4EtjkMWKYRhHQ X-IronPort-AV: E=Sophos;i="4.89,911,1367964000"; d="scan'208";a="24206856" Received: from mail-ee0-f46.google.com ([74.125.83.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Aug 2013 08:43:56 +0200 Received: by mail-ee0-f46.google.com with SMTP id c13so1947893eek.19 for ; Sun, 18 Aug 2013 23:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FciCPwjy2H6saOZneNGvZSC6zwielN4OJOD3IJkMDPQ=; b=BDlsCoCyFPc9skcR+voI3hA6xg4TSG4A9kLZD83qrf4uTyNguBPvnsdD7OOpqYK1lH oOZDgNn3IhFc1PO8NCaH4oZfkFvho+JUQm0JwsEdlgQwQzyzrqbcHEe07uGM5IixEdDZ ginKydCEXjPsDvXVj2xqEbhgg86rIgAT7zZl/EPk4IvzHB8PlQxCvhnX/gbQotkGNJB8 765wXePSfpMnROLOjx8yFoiMkZXlN2yOi1BBxAZIbRiRa3rkkzeBWPlNwd2lT7mIm2nL d4RY5CfWmVMt31QnS7HmQJkV7yHH2mX0amqHSFfDGkkghgZnCCd+zpdJ2yh0TPw2BGMd w3RQ== MIME-Version: 1.0 X-Received: by 10.15.43.13 with SMTP id w13mr20074463eev.37.1376894636131; Sun, 18 Aug 2013 23:43:56 -0700 (PDT) Received: by 10.14.10.68 with HTTP; Sun, 18 Aug 2013 23:43:56 -0700 (PDT) In-Reply-To: <20130819002023.GA11063@siouxsie> References: <20130818204213.GA7482@siouxsie> <20130818205305.GA7841@siouxsie> <20130818224024.GA10193@siouxsie> <20130819002023.GA11063@siouxsie> Date: Mon, 19 Aug 2013 00:43:56 -0600 Message-ID: From: Anthony Tavener To: oliver Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=089e01681f7eae304d04e447438e Subject: Re: [Caml-list] Early GC'ing --089e01681f7eae304d04e447438e Content-Type: text/plain; charset=ISO-8859-1 What I was hinting at with Gc.full_major (), is that if you still had a large amount of memory allocated after calling that, I think that means your program is still holding on to the values somewhere. In your loop, when you read in the data each time, is there any way something might leak? A hashtable holding reference to buffers? Or files left open? I tried searching for tools which might help with memory leaks or profiling, and got a recent presentation I hadn't seen: http://oud.ocaml.org/2012/slides/oud2012-paper13-slides.pdf Not that that is much help for you right now...! And I found these tips on GC params: http://elehack.net/writings/programming/ocaml-memory-tuning But it doesn't seem like it's a tuning problem, if the memory is still "live", especially after a full_major collection. Sorry I don't have much more help on this! On Sun, Aug 18, 2013 at 6:20 PM, oliver wrote: > ...strangely the resulting data is different for each run... > > > ...strange. > > > --089e01681f7eae304d04e447438e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What I was hinting at with Gc.full_major (), is that if yo= u still had a large amount of memory allocated after calling that, I think = that means your program is still holding on to the values somewhere.
In your loop, when you read in the data each time, is ther= e any way something might leak? A hashtable holding reference to buffers? O= r files left open?

I tried searching f= or tools which might help with memory leaks or profiling, and got a recent = presentation I hadn't seen:=A0http://oud.ocaml.org/2012/slides/oud2012-pap= er13-slides.pdf
Not that that is much help for you right now...!

But it doesn't seem like it's a tuning problem, if the m= emory is still "live", especially after a full_major collection.<= /div>

Sorry I don't have much more help = on this!



On Sun, Aug 18, 2013 at 6:20 PM, oliver <= ;oliver@firs= t.in-berlin.de> wrote:
...strangely the resulting data is different= for each run...


...strange.



--089e01681f7eae304d04e447438e--