在生产中滚动重启时，在构建应用程序 JAR 的过程中作为 AOT 编译的一部分可以加快这个过程（构建 JAR 会有所缓慢——你必须在某个地方支付编译时间的“罚金”）。
我们曾经将我们的应用程序 uberjars 作为源代码构建，但我们也在生产中发现启动时间较慢，因此我们在构建 uberjar 的过程中使用了 AOT 编译，这将最坏应用程序的生产启动时间从一分钟左右降低到几秒钟。
至于 CI，为了运行测试，它们必须被加载和编译，因此你实际上无法避免这部分时间。你唯一真正可选的是转向增量测试，只为更改了代码或依赖于更改了代码的部分运行测试。对于我们来说，这是转向 Polylith 的未来发展承诺之一，因为其内置的测试运行程序会根据 git 标签进行处理——但这只能在“一切都在 Polylith 中”时才会有这样的好处。
Alex 提到了加快开发加载的文档，我在工作中通过在类路径上创建一个本地的 classes 文件夹并定期为我们的源代码库中的每个主要“应用程序”手动启动一个 compile 步骤来使用这种方法。这意味着自上次编译以来没有更改的任何代码将仅使用现有的 .class 文件，无需在加载时通过 Clojure 编译过程——但如果 有 代码更改的话，它在加载时仍然需要编译。
在与 REPL 一起工作时，它对初始加载时间有很大影响，但随着时间的推移，由于越来越多的代码发生变化，它会“漂移”。然而，在工作时，我们倾向于使用生命期较长的 REPL，并修改代码时评估所有代码，因此缓慢首次加载问题并不那么讨厌，我并不总是使用 classes 事物。我所说的“生命周期较长的 REPL”是指持续的几个星期，有时甚至几个月。我主要的作业 REPL 已经运行了十天，它之所以这么“短”，是因为我遇到了停电，不得不重启开发机器。
