Force RecursiveFactorization to cache a bunch of precompiles

[ChrisRackauckas]

using OrdinaryDiffEq, SnoopCompile

function lorenz(du,u,p,t)
 du[1] = 10.0(u[2]-u[1])
 du[2] = u[1]*(28.0-u[3]) - u[2]
 du[3] = u[1]*u[2] - (8/3)*u[3]
end

u0 = [1.0;0.0;0.0]
tspan = (0.0,100.0)
prob = ODEProblem(lorenz,u0,tspan)
alg = Rodas5()
tinf = @snoopi_deep solve(prob,alg)

Before:
InferenceTimingNode: 2.668258/24.839223 on Core.Compiler.Timings.ROOT() with 51 direct children

After:
InferenceTimingNode: 2.285476/19.503069 on Core.Compiler.Timings.ROOT() with 54 direct children

[chriselrod]

As a general question, why the preference to inserting calls instead of using SnoopCompile-generated precompile statements?

[ChrisRackauckas]

Precompile statements don't stay correct, so Tim Holy suggested doing this. BTW, there's a lot of precompile statements in LoopVectorization.jl that were throwing warnings

[chriselrod]

Precompile statements don't stay correct, so Tim Holy suggested doing this. BTW, there's a lot of precompile statements in LoopVectorization.jl that were throwing warnings

Oh, still?