Compiler construction 导致JVM/CLR语言长时间启动的设计选择的基本原理？

我正在考虑设计一种编程语言，我希望它能以与CPython或Perl差不多的速度启动。为了在我的语言中做出正确的设计选择来达到这个要求，我正在研究现有的动态语言，看看它们的设计选择如何影响它们的启动时间。许多基于JVM或CLR的语言实现的启动时间比CPython或Perl长得多。这表明在JVM和/或CLR的设计中做出了设计选择，这导致了这种情况。这个选择是什么？为什么会这样

这是一个由三部分组成的问题：

动态JVM/CLR语言实现的启动缓慢到底是一个基本的设计问题，还是一个可以通过改进语言实现来纠正的小问题

如果是设计问题，那么JVM的哪些设计选择以及这些语言的哪些设计选择会导致这些语言比CPython和Perl具有更长的启动延迟？

启动缓慢会带来什么好处？也就是说，由于（2）中描述的设计选择，JVM/CLR动态语言有哪些好处是CPython和Perl所缺乏的

请注意，其他SO问题已经涉及“”以及各种JVM语言启动缓慢的原因。这个问题与那个问题不同，因为这个问题是关于设计权衡的；这么长的启动时间换来了什么

其他一些问题问用户如何加快各种JVM语言的速度（答案通常是有某种预先加载JVM的守护进程），但这不是我在这里要问的；我想问的是，如何设计一种语言（和/或虚拟机）来实现快速启动（无需预加载），以及由此带来的损失

背景研究 各种语言实现的速度 我在GNU/Linux机器上的非正式Hello World测试中对CPython和Perl进行了基准测试，发现它们在不到0.05秒的时间内启动。在这篇文章的其余部分，我会说“快”是指“启动时间不比CPython或Perl长很多”，而“慢”则是指其他

人们很容易发现JVM本身和/或Java启动缓慢（，）的观点，以及大约1秒或更长（，）的具体数字和基准测试（）。然而，两个Hello World JVM基准测试仅在0.04秒内启动（在GNU/Linux上）（，）

Clojure的启动时间约为0.6-1秒（，）；这比我的目标0.05秒慢了大约20倍。ClojureCLR甚至更慢（）。Clojure启动时间基准和讨论可以在博客帖子中找到

一位创业时间基准测试师表示，Clojure和JRuby的速度“明显慢于其他任何东西”（）；这也是测试的仅有的两种基于JVM的动态语言。另一个（非常古老的）基准测试表明，Jython的启动速度也非常慢（）。在这个问题上，我们关注的是动态语言，但是与此相关的是，Scala也不是非常快（）。有一个JVM方案称为Kawa（）。据报道，Kawa的启动时间约为0.4（），比Clojure快，但仍比我的目标高出一个数量级

在启动期间，这些实现在做什么？ 这两个（，）都得出结论，Clojure正在花费启动时间加载类并初始化Clojure.core命名空间。“Clojure应用程序启动性能”这个问题似乎是说Java启动时间和Clojure启动时间之间的区别是因为Java惰性地加载其标准库，而Clojure急切地加载其标准库。对所谓问题“”的回答包括“这只是一个可以纠正的实现问题，而不是一个基本的设计选择”（），以及）

一种说法是ClojureCLR的启动时间主要花在JIT上，而预JIT会显著缩短时间（尽管与CPython和Perl相比，它可能仍然很慢）

对于某些JVM或Java程序启动缓慢的原因，有一种解释是从标准库（）加载许多类文件的I/O操作。这一假设得到了一些基准测试的支持，这些基准测试显示“热启动”的JVM启动时间有了显著的提高，其中标准库类文件的内容可能已经加载到操作系统的缓存中。有人说，大部分启动时间都是由于类文件中的I/O读取，但这并不是因为数据量太大，而是因为磁盘上的数据组织不够理想（，）

JVM的字节码验证器可能对启动时间没有显著影响，因为验证器40%的加速仅转化为大型程序启动时间5%的加速（）

哪些设计选择（不会）导致启动缓慢？ 在（）中，Kariniemi得出结论，Clojure启动固有的启动速度较慢，这是因为设计选择包括动态特性。然而，我质疑这一结论，因为CPython和Perl实现了更快的启动，同时仍然提供了活力

字节码的使用不能成为原因，因为CPython也使用字节码

---

因为加载类文件的I/O似乎有问题，人们可能会怀疑底层的设计选择是提供一个大型标准库。但是，这不是原因，因为CPython还提供了一个大型标准库，并且启动速度并不慢。此外，尽管Java的缓慢性存在争议，但值得注意的是，Java必须在启动时加载rt.jar，然而根据一些基准测试，Hello World在Java中运行得很快。

启动时间由运行时实际开始执行任何“用户代码”之前所需的工作量决定