Slow compilation with SecondOrderODEProblem

General Usage
,
1

Is the following expected? (DifferentialEquations 7.16 in Julia 1.11.6)

using DifferentialEquations

function OneDimSpring2!(ddu, du, u, p, t)
    ddu[1] = 1.0 + 1.0/u[1]^2
end

du0 = [0.0]
u0 = [2.0]
tspan = (0.0, 50.0)

prob = SecondOrderODEProblem(OneDimSpring2!, du0, u0, tspan)

@time sol = solve(prob)

 46.927988 seconds (180.09 M allocations: 8.824 GiB, 8.56% gc time, 100.00% compilation time)

I know there have been huge improvements in loading and compilation time in DifferentialEquations so the 46s of compilation for a small ODE came like a surprise…

2

In doing so, we had to choose what to precompile and what not to precompile. We don’t precompile for SecondOrderODEProblem. We can, we very easily can from the infrastructure, but it would increase our precompile times while not improving the experience for most users. We can make this a preference or maybe even a subpackage which triggers the precompilation, but having it on by default probably isn’t the answer.

This probably gets easier as we split more out of OrdinaryDiffEq / DifferentialEquations by default, as when that is cut down then the user triggers what they need and so we can precompile more on the subsets.

1 Like
3

Thanks, that makes sense!

I’m curious about one thing though: if I rerun solve it’s quite fast as expected. But if I rerun the function definition (and what follows) it’s as slow as the first run. I understand that rerunning the function definition makes a new function with its own type, which means some previously compiled code cannot be reused. But how come the compile time could be reduced with precompilation, when running the code twice manually doesn’t help?

Is this not also about something more such as type annotations to force internal functions to be less specialized so they don’t get recompiled for every user function? If that’s the case then this might be something that could be improved for SecondOrderODEProblem without increasing precompile time?