From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 813797F02E for ; Thu, 20 Aug 2015 11:21:16 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of goswin-v-b@web.de designates 212.227.15.14 as permitted sender) identity=mailfrom; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BdBgAYm9VVmw4P49Rdg29prS2JXohJhXsCgTBMAQEBAQEBEgEBAQEBBgsLCSEuhCQBAQQyAVYLGAklDwUoiEwBGQm/B4l+H4YPAQEIAQEBARoEi1OEMl8XgwGBFAWVKIYqhkKBTYcYDI1jEINZhCVvAQGBBIFGAQEB X-IPAS-Result: A0BdBgAYm9VVmw4P49Rdg29prS2JXohJhXsCgTBMAQEBAQEBEgEBAQEBBgsLCSEuhCQBAQQyAVYLGAklDwUoiEwBGQm/B4l+H4YPAQEIAQEBARoEi1OEMl8XgwGBFAWVKIYqhkKBTYcYDI1jEINZhCVvAQGBBIFGAQEB X-IronPort-AV: E=Sophos;i="5.15,714,1432591200"; d="scan'208";a="143340175" Received: from mout.web.de ([212.227.15.14]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2015 11:21:15 +0200 Received: from frosties.localnet ([95.208.221.151]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MOzrj-1ZN6ya0FK3-006NUy for ; Thu, 20 Aug 2015 11:21:15 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.84) (envelope-from ) id 1ZSM26-0004Dn-CD for caml-list@inria.fr; Thu, 20 Aug 2015 11:21:14 +0200 Date: Thu, 20 Aug 2015 11:21:14 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20150820092113.GB15458@frosties> References: <55D4A2E4.7000303@tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55D4A2E4.7000303@tu-berlin.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:uhGDrGGYMbtJGteIY9cBeM8on2yVySn76XQbU6kg74JaVsIU8hj cP8XhUXuzcF0oWm7ReFKmeVNekNPnTP7ojaZ43lqvrYS4VSS3lhgvG2AgWpzAExBhyGMfyw VhgObWtr8VNx3m8huHFSl+pGmxyFiNz7aZjeUMXZTTA7hl5XN6jYkXleoiE4rbaL2b/6JH3 SwA9YYxUFTG1hAd//uaaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:VG93tWSuT54=:6hUHsbDtvlZ+C5TG1snyoG cSgoBJMfQDHqjAxBm1Ry9pIZ5jWgdEsBDmJw/ZjkyuJYY3mqVtRC2SrA6V4RtXhgYHmzTdBX/ i7rWxiwKopOZYvD8MRYZ3bnN9hBeccMaxy6kIdvOpAJU0nC7PigB+o/EQMwibtzTbJetzjPxQ Iun3L/S25prxsXoeQPceXhOQ/rJIBhBUCqCHt+oiAzpz7owniUVE6tr+qcOmaXt+PfM12nCCF m1clWjI4zsyepvLDYJt4vyI8aYFjO3hyoYruRMq4HO7KWJwqcW8fRLwtINSTZZX7VV1m2dJHC d8/16L2kvogRvl2JsWPTX72mpeVM+xTfu8bCYSAY8dExG/Oh5IharPVIFIiXH7vGL/5Jm8n5v tUbZbfCvdY0mCims3hEY1dAt2jT7AF4Gh5ZKvepcZB0+yoXLVlRu08vAaC5YGmHjQVmMuzH4d dJC7flCZz4AYc+JyTjHwiJEVT1YtDKh/9wFPMwhcoIG6+Age7FPBHQHYPTdSl/6q0cocnCqXh D7GJjn5PoUw//PAFxHdgoJKgCShol5yb4Zcsy01fhpOC0IKZnMfs37GiJwuB+mvBuzsy9Z24o AKonl6xVAm+vDTEtLsjkNE/zO7YF2uuzdzS1bWXCQSM0MlnZDK6mhhw0QF9Cx2GocSveGm54J tJYZTzGnbtLqb9lYpCNzH1RRVT2CC1wfUi/IdWy/wig8aLSC7Hztwm62hO99lte/jRvtSFmtp WbyaLKYnrv0uO4WE Subject: Re: [Caml-list] Size of .cmo / .cmi workload of the compiler On Wed, Aug 19, 2015 at 05:38:12PM +0200, Christoph Höger wrote: > Dear all, > > I autogenerate a rather large (> 12k) set of ocaml modules containing > classes which are parameterized over their final representation to allow > for hierarchic classes with polymorphic open recursion. > > My compilation scheme seems to work well in principle, but I am reaching > a frustrating limit in practice: The compilation of the generated ml > files seems to run superlinear (in fact it seems to depend on the > hierarchical location of a class). As it turns out, the generated .cmo > and .cmi files are quite large (up to several hundreds of kb). When I > generate the .mli files or dump the .cmo files however, the output is > quite small (several hundred instructions in the bytecode, the .mli file > contains quite complex objects but still human readable). > > Is there any known issue that leads to: > > 1. non-linear runtime when compiling inter-module classes > 2. huge .cmo files outside of the actual bytecode > > The generated source code can be found here: > > https://www.dropbox.com/s/cllc0xikv9zwu1k/doesnotscale.tar.bz2?dl=0 > > To test the behavior, unpack and run > > ocamlbuild ModelicaXX5FElectricalXX5FMachines.cmo > > (there might be type-errors in the generated files somewhere, though). > > Any advice or comments are deeply appreciated. > > Christoph When you inherit a class the compiler has to parse that class and everythig it inherits. So it is no surprise to get slower the longer your inheritance chain gets. And I assume each step in the chain adds some method so your interface gets bigger and bigger. Sounds like the cmi file contains the full interface and not just a reference to the inherited class(es) and the additional code while dumping the cmo file only shows the additional code. MfG Goswin