You’re absolutely right — I was wrong. As Chris notes in his magnum opus of DifferentialEquations.jl #786:
The last thing, and the major step forward, was SciML/DiffEqBase.jl#698 (comment) . As it explains, using a function barrier can cause inference to not know what functions it will need in a call, which makes Julia seem to compile a whole lot of junk . That can probably get fixed at the Base compiler level to some extent, as the example there was spending 13 seconds compiling
(::DefaultLinSolve)(::Vector{Float64}, ::Any, ::Vector{Float64}, ::Bool)junk which nobody could ever call, since any call to that function would specialize on the second argument (a matrix type) and so it should’ve been compiling(::DefaultLinSolve)(::Vector{Float64}, ::Matrix{Float64}, ::Vector{Float64}, ::Bool). But since that call was already precompiled, if inference ends up good enough that it realized it would call that instead, then bingo compile times dropped from 16 seconds to sub 3. That’s a nice showcase that the easiest way to fix compile time issues may be to fix inference issues in a package, because that can make Julia narrow down what methods it needs to compile more, and then it may have a better chance of hitting the pieces that you told it to precompile (via a using-time example in a precompile.jl).