From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 4FABFBC37 for ; Wed, 29 Apr 2009 08:18:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskBAPeN90nUGyoClGdsb2JhbACWbwEBAQEJCwgJEQOlJJF3g3QFh3M X-IronPort-AV: E=Sophos;i="4.40,264,1238968800"; d="scan'208";a="26954084" Received: from smtp2-g21.free.fr ([212.27.42.2]) by mail3-smtp-sop.national.inria.fr with ESMTP; 29 Apr 2009 08:18:47 +0200 Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 1B15C4B00D9; Wed, 29 Apr 2009 08:18:41 +0200 (CEST) Received: from [192.168.0.3] (rke75-3-82-229-183-156.fbx.proxad.net [82.229.183.156]) by smtp2-g21.free.fr (Postfix) with ESMTP id 02B634B0078; Wed, 29 Apr 2009 08:18:38 +0200 (CEST) Message-ID: <49F7F135.5080504@gmail.com> Date: Wed, 29 Apr 2009 08:18:29 +0200 From: Alain Frisch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brighten Godfrey Cc: Markus Mottl , OCaml List Subject: Re: [Caml-list] Strange performance bug References: <324B24CA-9671-42C0-B722-C7710C0C45C7@cs.berkeley.edu> <59BD1B3A-B449-4963-9910-ED5E755D00E6@cs.berkeley.edu> In-Reply-To: <59BD1B3A-B449-4963-9910-ED5E755D00E6@cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 bug:01 regexp:01 bug:01 pcre:01 regexps:01 ocaml:01 pcre:01 regexps:01 ocaml:01 parsed:01 wrote:01 compile:01 parsing:01 Brighten Godfrey wrote: > (Changing to the precompiled regexp does make this bug go away -- but so > do many other small changes, like commenting out the last line of the > code, *after* the parsing is complete.) This last line (List.length first) + ...) forces the values first, second and third to remain alive. How big are these values in memory? I would suggest to look closely at the memory usage and GC behavior of your program. I did not investigate your problem, so here is a random speculation: If the parsed file is big enough, PCRE will compile a lot of regexps; maybe the OCaml PCRE binding does not evaluate properly the memory usage of these regexps and so OCaml does not trigger a GC soon enough to release the compiled regexps; the process memory grows and the OS starts to swap your process. Alain