Lisp的二进制文件的大小(Lisp binary size)

正如我在人工智能感兴趣，我最近决定给Lisp的一个尝试。编译后非常基本的应用程序与Common Lisp的编译器SBCL我注意到，生成的二进制文件是非常大的（大约43MB）。我感兴趣的其中的原因。是（普通）口齿不清这个常见的问题，什么是这种行为的技术背景？

有Common Lisp中实现多种不同的架构：

翻译员
字节码引擎（CLISP是一个例子）
经由C编译器编译（ECL是一个例子）
本地代码编译器（SBCL，LispWorks，Clozure CL）

典型地，该解释器和字节码引擎使用的内存量最小。 CLISP因而是非常小的。 SBCL OTOH产生比较大的本地代码。

其次，有几种不同的方法来创建应用程序 ：

保存图像
节能优化的图像
编译为C代码

再加上一些更像编译成的DLL。

SBCL基本上没有1.转储包含数据和代码存储器，并且包括运行时间。因此，一切你正在运行的系统（文档，源代码的链接，参数列表，符号名，调试相关信息，编译器本身，...）将被倾倒入图像+运行。此外SBCLs生成的本机代码是大的，有潜在的运行时存储器中的大量的代码信息和SBCL包括它的所有自己的功能（包括编译器）。

在与这样的未优化的应用程序或图像（与外部运行时）开发一个经常工作（S / ED），以节省时间来加载代码和数据。我与均大于100MB的图像用它自己。

例如LispWorks确实1和2它的输送过程，其中可以选择性地去除的东西（如文档，一些功能，例如，编译器，源引用，...）。这也是使用树摇，可以删除未使用的功能。

优化的图像也可能意味着把它写在一些压缩方式和解压它启动起来。 SBCL允许此例如。

变体3在过去所做的，但当前未使用（除了一些专门的工具和应用程序等）。 Thinlisp，斯特拉，CYCL，...是这样的递送工具。在过去也有这样的工具，商业供应商（但是，这并不存在没有更多的，IIRC它是最后一个拥有者/被甲骨文）。更新：实际上代替MoCl ，iOS和Android最近的Common Lisp的应用程序生成器做的。它采用Common Lisp的一个大子，并将其编译成小的，独立的移动应用程序。例如在iOS它产生于苹果提供的C编译器的紧凑C代码。