From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 CDFDC7EEBF for ; Thu, 20 Aug 2015 11:12:45 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of fabrissimo@gmail.com) identity=pra; client-ip=209.85.215.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of fabrissimo@gmail.com designates 209.85.215.54 as permitted sender) identity=mailfrom; client-ip=209.85.215.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f54.google.com) identity=helo; client-ip=209.85.215.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-la0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CDAgCymdVVlDbXVdFdg29pBoMfqXCSQYUvSoErB0wBAQEBAQESAQEBAQcLCwkfMIQkAQEEEhEdAS0LAQMMAQUFCw0CAgkdAgIiEgEFAQoSBhMSEId3AxINq0mBLz4xi0CEZXWKIScDCoVXAQsaAQUOgRSDN4Z6hDIlgyOBQwWFbwyPLYUFh2qBSkaUQYIdEiOBFxdJg0U8MwEBgQSBRgEBAQ X-IPAS-Result: A0CDAgCymdVVlDbXVdFdg29pBoMfqXCSQYUvSoErB0wBAQEBAQESAQEBAQcLCwkfMIQkAQEEEhEdAS0LAQMMAQUFCw0CAgkdAgIiEgEFAQoSBhMSEId3AxINq0mBLz4xi0CEZXWKIScDCoVXAQsaAQUOgRSDN4Z6hDIlgyOBQwWFbwyPLYUFh2qBSkaUQYIdEiOBFxdJg0U8MwEBgQSBRgEBAQ X-IronPort-AV: E=Sophos;i="5.15,714,1432591200"; d="scan'208";a="174280761" Received: from mail-la0-f54.google.com ([209.85.215.54]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Aug 2015 11:12:41 +0200 Received: by laba3 with SMTP id a3so18691878lab.1 for ; Thu, 20 Aug 2015 02:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=jYoTOCnXXMqujju4KXqy3e2c8EIufrtMN9JjJnikGIc=; b=JzEpzkJo6w38Qd0t90Pso89RNBmaB7t1E5sJ49/pp2YAlmmgNfsnj1+bhH7v3aAjFF CAAkamIOWOK7T3UE1Jpbxs4WsOnViHORhDDJT3D7AUFAODro3C0BEGgw87UhLH9jlt7w 9a4IVkTeRVO32DqmEihG4yu8HMgh4aOU/nxRmuP4KY0YCWg8v12C4msdb/ySwpG+FS0x KQFm6eT8oiYx5DNgNmin77JAPIGdv20kRCdzR0hq3Kxe56UzYn7VYLuwuEwNLI/eG3Nx fRs86HlyYCJIUEr4m7sWzKimz93KgF+J3xggtee6o9kF0WUIyNZ3EoEca5KIxr05sM1g Zt+g== X-Received: by 10.152.5.201 with SMTP id u9mr2017022lau.26.1440061960355; Thu, 20 Aug 2015 02:12:40 -0700 (PDT) MIME-Version: 1.0 Sender: fabrissimo@gmail.com Received: by 10.25.125.4 with HTTP; Thu, 20 Aug 2015 02:12:20 -0700 (PDT) In-Reply-To: <55D4A2E4.7000303@tu-berlin.de> References: <55D4A2E4.7000303@tu-berlin.de> From: Fabrice Le Fessant Date: Thu, 20 Aug 2015 11:12:20 +0200 X-Google-Sender-Auth: saZ_b8OwU6WojHm_XsDGAvjsyuA Message-ID: To: =?UTF-8?Q?Christoph_H=C3=B6ger?= Cc: Ocaml Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Size of .cmo / .cmi workload of the compiler One possible explanation: object types are almost always expansed in the .cmi files (and probably in the debug section of .cmo files), and all the more if all the classes are defined in different .cmi files (since each type is loaded from a different file, there is no in-memory sharing when the same type appears in two different modules). When we created the Try-OCaml site for Js-of-OCaml (https://try.ocamlpro.com/js_of_ocaml/), we ran in the same problem, because js-of-ocaml uses object types for most values, and so the .cmi files that were loaded were much bigger than for the original Try-OCaml site (something like 12 MB instead of 1 MB to load the toplevel). We ended up writting a compressor of .cmi files. If you are using 4.01.0, you can download a bytecode image of that compressor in the former repository of try-ocaml: https://github.com/OCamlPro/tryocaml/tree/master/toplevellib/toplevellib-4.= 01.0 and then, you can test it on one of your .cmi files to see if it can compress these files (for Try-OCaml, the image decreased from 12 MB to 2 MB if I remember correctly). Then, you could run it automatically on each .cmi files after it has been generated by ocamlc, if it is indeed the source of the problem. --Fabrice On Wed, Aug 19, 2015 at 5:38 PM, Christoph H=C3=B6ger 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=3D0 > > 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 > > -- > Christoph H=C3=B6ger > > Technische Universit=C3=A4t Berlin > Fakult=C3=A4t IV - Elektrotechnik und Informatik > =C3=9Cbersetzerbau und Programmiersprachen > > Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin > > Tel.: +49 (30) 314-24890 > E-Mail: christoph.hoeger@tu-berlin.de > > -- > 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 Fabrice LE FESSANT Chercheur en Informatique INRIA Paris Rocquencourt -- OCamlPro Programming Languages and Distributed Systems