Wow, in that case I’m glad I posted that reply. Over the years I’ve occasionally gotten a bit of grief that “julia’s compiler is slow because its parser is written in scheme”, which is not the case. It would be great if the front-end were the bottleneck and we could fix it just by rewriting that code in julia or C.
We have various ways of timing things and have done a bunch of profiling of the compiler. The breakdown depends a bit on what you compile, but generally the story is
isel time >= LLVM optimizer time > julia optimizer > type inference > front-end
The typical cause of precompile slowness is packages running code at load time, which requires codegen. If a package just contains, say, a bunch of method definitions and no top-level code then it should precompile pretty quickly. Of course, if we could save native code then running code at load time could become a good thing, but now it results in a double cost (both when precompiled and used). Plotting is a high-profile case, where despite precompilation it still takes a long time to get the first plot.
Another source of precompile slowness is that each package is compiled by a separate process, and each of those processes needs to load all dependencies of each package. That adds a small super-linear term to the time.