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=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id C8100BC37 for ; Wed, 29 Apr 2009 08:37:34 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoBAGqS90nUGyoGkWdsb2JhbACWbwEBAQEJCwoHEQO3FYN0BYdz X-IronPort-AV: E=Sophos;i="4.40,265,1238968800"; d="scan'208";a="25336831" Received: from smtp6-g21.free.fr ([212.27.42.6]) by mail2-smtp-roc.national.inria.fr with ESMTP; 29 Apr 2009 08:37:33 +0200 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 25996E08068; Wed, 29 Apr 2009 08:37:27 +0200 (CEST) Received: from [192.168.0.3] (rke75-3-82-229-183-156.fbx.proxad.net [82.229.183.156]) by smtp6-g21.free.fr (Postfix) with ESMTP id B9EE9E08139; Wed, 29 Apr 2009 08:37:24 +0200 (CEST) Message-ID: <49F7F59B.7070204@frisch.fr> Date: Wed, 29 Apr 2009 08:37:15 +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> <49F7F135.5080504@gmail.com> <08C6A0FC-90F2-43A4-AB78-4A3B68291FAA@cs.berkeley.edu> In-Reply-To: <08C6A0FC-90F2-43A4-AB78-4A3B68291FAA@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 pcre:01 regexps:01 ocaml:01 regexp:01 ocaml:01 pcre:01 wrote:01 parsing:01 heap:01 caml-list:01 alain:01 alain:01 Brighten Godfrey wrote: > That occurred to me too, but there is no swapping. The process uses > less than 40 MB of memory. Also, this wouldn't explain why it suddenly > becomes slow exactly when it starts parsing the file the second time. This point is interesting: it is where PCRE starts compiling a lot of regexps while the OCaml heap is already full of non-garbage value (the value bound to first). For each allocated regexp, the OCaml PCRE binding pushes some pressure on the OCaml GC; maybe, then, the GC runs too often for the amount of memory it can really release. -- Alain