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 587D77EEBF for ; Wed, 19 Aug 2015 17:38:15 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=pra; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=mailfrom; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.tu-berlin.de) identity=helo; client-ip=130.149.7.33; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="postmaster@mail.tu-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AbAQCBodRVnCEHlYJdg29pgyW8HAqHPkwBAQEBAQESAQEBAQEICwkJIS6ETQ8BRTYCBRYLAgsDAgECAVgGAgEBiCoNqwmPY4VakHAEgSKOY3aCFwwvEoExBZUkb5RpkUaEJW8BAYEEgUYBAQE X-IPAS-Result: A0AbAQCBodRVnCEHlYJdg29pgyW8HAqHPkwBAQEBAQESAQEBAQEICwkJIS6ETQ8BRTYCBRYLAgsDAgECAVgGAgEBiCoNqwmPY4VakHAEgSKOY3aCFwwvEoExBZUkb5RpkUaEJW8BAYEEgUYBAQE X-IronPort-AV: E=Sophos;i="5.15,710,1432591200"; d="scan'208";a="174162684" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2015 17:38:14 +0200 X-tubIT-Incoming-IP: 130.149.172.228 Received: from brego.uebb.tu-berlin.de ([130.149.172.228]) by mail.tu-berlin.de (exim-4.76/mailfrontend-8) with esmtpsa [UNKNOWN:AES128-SHA:128] for id 1ZS5RM-0004MB-m7; Wed, 19 Aug 2015 17:38:14 +0200 To: caml-list@inria.fr From: =?UTF-8?Q?Christoph_H=c3=b6ger?= X-Enigmail-Draft-Status: N1010 Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_Berlin?= Message-ID: <55D4A2E4.7000303@tu-berlin.de> Date: Wed, 19 Aug 2015 17:38:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: [Caml-list] Size of .cmo / .cmi workload of the compiler 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 -- Christoph Höger Technische Universität Berlin Fakultät IV - Elektrotechnik und Informatik Übersetzerbau und Programmiersprachen Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin Tel.: +49 (30) 314-24890 E-Mail: christoph.hoeger@tu-berlin.de