在生产中进行滚动重启时，将Ahead-of-Time（AOT）编译作为应用程序JAR构建过程的一部分将加快这个过程（构建JAR会慢得多——你必须为编译时间“惩罚”付费）。
我们之前以源代码的形式构建我们的应用uberjar，但我们也遭受了生产中缓慢的启动时间，因此我们切换到在uberjar构建过程中进行AOT编译，这使得我们的生产启动时间从最差应用程序的约一分钟降低到仅几秒钟。
至于持续集成/持续部署（CI），为了运行测试，测试必须被加载和编译，因此你实际上无法避免这段时间 某处 的开销。你唯一真正的选择将是转向增量测试，并且只为更改的代码或依赖于更改的代码运行测试。对于我们来说，这是切换到Polylith的未来的一个承诺，因为它的内置测试运行器根据git标签找到这一点——但这只有在你有“所有”代码在Polylith中时才会带来好处。
Alex提到了加速开发加载的文档，我通过在类路径上创建一个本地的classes文件夹并定期为我仓库中的主要“应用”手动启动compile步骤来使用它。这意味着自上次编译以来没有更改的任何代码将只使用现有的.class文件，并在加载时不经过Clojure编译过程——但任何已更改的代码在加载时仍然需要编译。
在REPL（读/eval/output）环境中工作时，这会对初始加载时间产生很大影响，但随着时间的推移，它会“漂移”，因为越来越多的代码发生变化。然而，在工作中，我们倾向于拥有较长时间的生命周期REPL，并像修改代码一样从头评估所有代码，因此第一次缓慢加载的问题并不那么令人讨厌，而且我不总是在做classes这件事情。当我提到“长时间运行的REPL”时，我是指几周，有时甚至是几个月。目前我主要的工作REPL已经运行了十天了，它这么“短”的唯一原因是我遭遇了电力中断，不得不重启我的开发机器。
