From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA13555; Thu, 28 Jun 2001 12:03:26 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 MAA13660 for ; Thu, 28 Jun 2001 12:03:25 +0200 (MET DST) Received: from quetelet.bik-gmbh.de (quetelet.bik-gmbh.de [194.233.237.132]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f5SA3KD05778; Thu, 28 Jun 2001 12:03:21 +0200 (MET DST) Received: from hars by quetelet.bik-gmbh.de with local (Exim 3.12 #1 (Debian)) id 15FYd3-00077x-00; Thu, 28 Jun 2001 12:02:29 +0200 Date: Thu, 28 Jun 2001 12:02:29 +0200 From: Florian Hars To: Xavier Leroy Cc: caml-list@inria.fr Subject: Re: [Caml-list] Where does Ocaml spend all the time? Message-ID: <20010628120229.B25747@hars> References: <20010628101635.A25747@hars> <20010628103724.A11414@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010628103724.A11414@pauillac.inria.fr>; from Xavier.Leroy@inria.fr on Thu, Jun 28, 2001 at 10:37:24AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, Jun 28, 2001 at 10:37:24AM +0200, Xavier Leroy wrote: > string_equal is the string comparison operator (i.e. Caml's = operator > at type string->string->bool). Yes, that is one of the functions that I expected to take a lot of time, since the program does a lot of string comparision and matching. I was more surprised by the time spent in the _code_(begin|end) functions, what are these? Why are they called and by whom? > At any rate, the GC-related functions account for only 25% of the > running time (which is typical for symbolic processing, but a bit high > for numerical processing) So this is OK (except that it is 25% of quite a lot of time :-) > so the "order of magnitude" slowdown that > you mention corresponds to other factors than just GC overhead Once the functionality is complete, I'll work on some details of the algorithms. > My experience is that carefully written Caml code always deliver at > least 50% of the performance of equivalent, carefully written C code. Yes, that was my expectation, too, after reading some comparisions. I'll try to see if the recomendations from the QandA help. CAMLRUNPARAM='o=100' alone gives another two to three seconds, this is a good start. Yours, Florian Hars. ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr