Type instability can make ode4 very slow

[marius311]

I've noticed ode4 can get extremely slow compared to ode45 with the same number of steps or say a hand-written rk4 solver. I tracked this down mostly due to a type instability in oderk_fixed, most impactful on the inner-most loop here; none of ys, ks, or dt involved there are inferred. You can see by running,

@code_warntype ODE.oderk_fixed(identity,Float64[1,1],Float64[0,1],ODE.bt_rk4)

I could hazard a solution myself, although I'm a bit confused about the status of this repository. Is this dead in favor of DifferentialEquations.jl? Or is this part of it? (I've never actually used DifferentialEquations.jl tbh, as I liked the lightweightedness of this one).

[ChrisRackauckas]

Is this dead in favor of DifferentialEquations.jl?

What is dead or alive is up to the community. ODE.jl is only dead if no one decides to work on it. That said, I do most of the development and maintenance for JuliaDiffEq, and I don't work on ODE.jl because anything that can currently be done with ODE.jl can be done faster (with the current tools) and more flexibly in DifferentialEquations.jl. And since everything in the issues wishlist (except for retcodes, which are planned) is implemented in DifferentialEquations.jl, I see it as superseded and don't plan on spending development time here.

However, I am happy to review/merge PRs, and will keep up maintenance (making sure it is compatible with the latest Julia and DifferentialEquations.jl). This library will grow if others put time in.

Or is this part of it?

You can use ODE.jl from DifferentialEquations.jl. Generally not advised, but can help when migrating.

as I liked the lightweightedness of this one

I understand. But from a development perspective, that lightweighted-ness makes it difficult to reuse codes for timestepping, event handling, etc., and makes it difficult to write generic parameter estimation APIs and all of that good stuff. So my own personal goals (building a large ecosystem of fast interconnected methods for a wide array of hybrid differential equations and analysis tools) don't align with the goal of ODE.jl (what I see as: a simple yet effective ODE library for teaching and prototyping).

This was all a long-winded way of saying:

I could hazard a solution myself

Please do!

I hope this clarifies everything.

[marius311]

Thanks for the explanation, that's very helpful. I agree there's nothing to stop people from working on ODE.jl, but since it sounds like most of the effort is concentrated elsewhere, I'm guessing its most efficient if I do so also. That said I may still submit a PR for this particular issue, but I'll probably give OrdinaryDiffEq.jl a go for this particular problem I'm on now.