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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id E7BFD7F30A for ; Mon, 25 Feb 2013 14:31:18 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.186 as permitted sender) identity=helo; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYCAEJnK1HU4366Zmdsb2JhbABFr1iRe4EEFg4LCxMBFAMkgh8BAQQBOjQLQF0JEgYTCQmHbwMJCgi1DgOJLxWIdYVeJgeDQAONfIUAhF6SUIFoJA X-IPAS-Result: AiYCAEJnK1HU4366Zmdsb2JhbABFr1iRe4EEFg4LCxMBFAMkgh8BAQQBOjQLQF0JEgYTCQmHbwMJCgi1DgOJLxWIdYVeJgeDQAONfIUAhF6SUIFoJA X-IronPort-AV: E=Sophos;i="4.84,735,1355094000"; d="scan'208";a="4379070" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Feb 2013 14:31:18 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-210-035.pools.arcor-ip.net [94.219.210.35]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0McEqN-1URlcA3tlX-00JcnA; Mon, 25 Feb 2013 14:31:18 +0100 Received: from samsung (ip-5-146-55-186.unitymediagroup.de [5.146.55.186]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 89E96C00CF; Mon, 25 Feb 2013 14:31:17 +0100 (CET) Date: Mon, 25 Feb 2013 14:31:13 +0100 From: Gerd Stolpmann To: Francois Berenger Cc: caml-list@inria.fr In-Reply-To: <512AC78E.7070908@riken.jp> (from berenger@riken.jp on Mon Feb 25 03:08:14 2013) X-Mailer: Balsa 2.4.11 Message-Id: <1361799073.2723.5@samsung> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:64w4svVENhu4KjdtXkgBGrAAAqgscEwvPbXt3o+tCbM VejdFau0tJqU6KyWWto2Vk2jdOJ/ecIvzjirUh1wtpCdXtuxfQ EbAXNNB/MdRFbvtmKT4Ne0t3f9l1VsP+zhrwEQ3N0bUuRWUAzb UOKCKWJbQSZkntxGKWET46EeSdHIdbJkgrhi5oB6rbIiUepztQ 2eLGB4C2LPRqutSCkEmv99S0Cir1e2AIUZT9gxHpDlmwoZxDPV y5Xfxmj3pMyCZG1/8I9NKnkdmmlSwREbWGTWo8Pvv4m1tGX3jW fFNcxBfirASjnNLgdmEa8yN6IC5qvvaSye65aRddZt8dk9y8UF IEJpBBCG9XwOpN2DK7kc= Subject: AW: [Caml-list] What is triggering a lot of GC work? Am 25.02.2013 03:08:14 schrieb(en) Francois Berenger: > Hello, >=20 > Is there a way to profile a program in order > to know which places in the source code > trigger a lot of garbage collection work? >=20 > I've seen some profiling traces of OCaml programs > of mine, sometimes the trace is very flat, > and the obvious things are only GC-related. >=20 > I think it may mean some performance-critical part > is written in a functional style and may benefit > from some more imperative style. This is really a hard question, and I fear an allocation profiler=20=20 cannot always answer it. Imperative style means to use assignments, and=20= =20 assignments have often to go through caml_modify, and are not as cheap=20= =20 as you would think. In contrast, allocating something new can usually=20=20 avoid caml_modify. This can have counter-intuitive consequences. Yesterday I sped an=20=20 imperative program up by adding allocations! The idea is so strange=20=20 that I need to report it here. The program uses an array for storing=20=20 intermediate values. Originally, there was only one such array, and=20=20 sooner or later this array was moved to the major heap by the GC.=20=20 Assigning the elements of an array in the major heap with young values=20= =20 is the most expensive form of assignment - the array elements are=20=20 temporarily registered as roots by the OCaml runtime. So my idea was to=20= =20 create a fresh copy of the array now and then so it is more often in=20=20 the minor heap (the array was quite small). Assignments within the=20=20 minor heap are cheaper - no root registration. The program was 10%=20=20 faster finally. My general experience is that optimizing the memory behavior is one of=20= =20 the most difficult tasks, especially because the OCaml runtime is=20=20 designed for functional programming, and short-living allocations are=20=20 really cheap. Usual rules like "assignment is cheaper than new=20=20 allocation" just do not hold. It depends. Gerd >=20 > Regards, > F. >=20 >--=20 > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------=