在生产中进行滚动重启时，将AOT编译作为应用程序JAR构建过程的一部分可以加快速度（构建JAR将明显变慢——你必须承担编译时间的“惩罚”）。
我们过去一直是用源代码构建我们的应用uberjars，但我们也遇到了生产中启动时间慢的问题，所以我们改为在uberjar构建时使用AOT编译，这使得我们的生产启动时间从最差应用的几分钟降低到几秒钟。
至于CI，为了运行测试，它们必须被加载和编译，因此你实际上无法避免这种时间 somewhere。那里你唯一真正的选择是转向增量测试，只运行已更改的或不依赖于已更改的代码的代码的测试。对于我们来说，这是转向Polylith的未来的承诺之一，因为其内置的测试运行程序可以根据git标签找出这一点——但这种好处只在你拥有“一切”在Polylith上时才会到来。
Alex提到了关于加快开发加载的文档，我在工作中通过在我的类路径上有一个本地的classes文件夹，并定期为本库中的主要“应用”手动启动一个compile步骤来实现这一点。这意味着自上次编译以来没有更改的任何代码都将使用现有的.class文件，并且不需要在加载时通过Clojure编译过程——但任何更改过的代码仍然在加载时需要编译。
在REPL中工作时，对初始加载时间有很大影响，但随时间推移，“漂移”得越来越严重。然而，在工作中，我们倾向于拥有寿命相当长的REPL，并在修改代码时评估所有代码，所以慢第一加载问题不是很讨厌，我并不总是困扰于classes的事情。当我提到“长远活期REPL”时，我的意思是几周，有时甚至是几个月。我的主要工作REPL现在已经运行了十天，它这么“短”的唯一原因是我遇到了停电，不得不重新启动我的开发机器。
