Could an AOT compilation cache speed up library loading times?

Question

Back in 2018, Alex Miller mentioned on ClojureVerse that it could be possible to implement a class compilation cache for Clojure to speed up loading libraries:

Rich and I have been kicking around some interesting ideas on a class compilation cache that would be integrated with core and that research is in scope for Clojure 1.10 but no guarantees on anything. Potentially it would combine the benefits of publishing source-only but the performance of AOT. It is inherently silly to recompile the same lib source file over and over when it’s not changing.

Is this idea still on the radar? It seems like it could give a nice speed-up if it's feasible.

Answer 1

I have taken a couple spikes at this idea both in the compiler and in the CLI and in short, it’s tricky. While the idea is still kicking around, the last time we looked at it, we concluded that the tools already existed to make such a cache on a per application basis (which avoids much of the complexity) and wrote this guide on how to do so:

https://clojure.org/guides/dev_startup_time

That probably needs a redo at this point to take into account tools.build but the idea is the same.

Comments

My experience is that with the manual AOT compilation as described in the guide, people run into problems that confuse even very experienced developers. Once you realise that it's an AOT problem, the solution is simple: just re-compile. I was hoping that there would be a way to automate away the tricky situations, but I understand that it is difficult.

---

The compilation described in the guide is the same compilation that happens at runtime and I think there is a lot of unfounded fear about using it. The issues people sometimes see with AOT fall into a couple categories - one is when you have layers of compiled and uncompiled code and protocols are getting recompiled. With the guide approach this doesn’t happen, because everything is compiled in load order, just like it does at runtime. Another is with changing compiled things at the repl that have runtime effects - there are some things there that we are hoping to work on in 1.12. Many people have used the approach in the guide and found it significantly improved startup time and is not as prone to problems as you think (specifically because it follows the load order of your app). Try it and report issues here!