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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 2CD73BB9C for ; Wed, 14 Sep 2005 04:25:01 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j8E2P0ax017312 for ; Wed, 14 Sep 2005 04:25:00 +0200 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 EAA26554 for ; Wed, 14 Sep 2005 04:25:00 +0200 (MET DST) Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j8E2Oxa1017295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 14 Sep 2005 04:25:00 +0200 Received: from [80.229.56.224] (helo=chetara) by pih-relay04.plus.net with esmtp (Exim) id 1EFMxF-0001lW-4C for caml-list@inria.fr; Wed, 14 Sep 2005 03:24:57 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml users Subject: Profiling garbage Date: Wed, 14 Sep 2005 03:21:42 +0100 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200509140321.43045.jon@ffconsultancy.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 432789FC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 432789FB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; garbage:01 optimise:01 garbage:01 minor:01 allocating:01 ocaml:01 memoizing:01 ocaml:01 presenta:98 recycling:98 ...:98 frog:98 graph:01 data:02 caml:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 I've recently been trying to optimise Presenta. The profiling results surprised me. Most of the time was spent in the GC, invoked by "". I assumed this meant that the GC was recycling enormous amounts of garbage from the old generation. Had it been recycled from the young generation then I assume the calls to the (minor) GC would be invoked by the allocating function - is that right? Anyway, the best way I found to track down the offending function was to write lots of extra code to spew out Gc.stat results and look at the amount of data being allocated by each function call. Doing this by hand is very tedious, of course. So I'm wondering, are there any tools to profile allocation and collection on a per function basis for OCaml code? I'm thinking of something along the lines of gprof results but showing space rather than time taken. I managed to find the offending function by hand this time - it was retypesetting the entire document every frame, regenerating the scene graph. Memoizing it improved the performance of the whole program by an order of magnitude. So this is definitely an optimisation trick worth remembering... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists