Refactor some core functionality into smaller functions for more compilation cache reuse

[ChrisRackauckas]

As noted in this post (https://stackoverflow.com/questions/47501844/julia-differentialequations-jl-speed/47507933#47507933), DiffEq aggressively specializes on each function. This causes a compilation phase between each new ODE function. However, we can lessen that burden by making less functions (or parts of functions) explicitly depend on the ODE function. Since the integrator is strongly typed with the function, this would mean writing some functions as independent of the integrator. For example, this used to be inline in the init function:

https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/solve.jl#L329-L362

but since it's now refactored out, it's compiled one and shared between all functions. I am not sure how to profile compilation time, but I would believe most of the time is spent in the "inner logic" functions here:

https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/integrators/integrator_utils.jl

All of these functions are functions of integrator which is why they specialize each time, but many of them are not dependent on f so it may be possible to make this not specialize on f.

[ChrisRackauckas]

@vchuravy had an interesting idea of splitting the integrator into have its own state type, and that can make it easier to pass around to subfunctions. I think we can take like these fields:

https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/integrators/type.jl#L54-L84

along with k and dt and make those the state type. So then the integrator would be u, t, state, opts, prob, and f (does it need f? I think that was pulled out of prob for the DDE solver once but isn't used now, so instead it could just be prob and refer to f as prob.f. @devmotion ). Then we can pass those five variables into functions, and only those with prob or prob.f would actually specialize (which ideally is just perform_step and a few others).

Then we should also check if inlining the interpolation functions actually helps or if it just gives us more compilation time. My guess is the latter. @ranocha did you benchmark this once when looking at the ellipsis notation stuff?

From the looks of it, I don't think it would be difficult to get rid most of this extra function specialization compilation time.

[devmotion]

I like the state proposal. I just did a quick grep -r "\.f" * on DelayDiffEq, and it seems the DDE solver does not require a separate field of f in ODEIntegrator (we only use field f in DDEIntegrator; this function is constructed during initialization and not equal to prob.f of the DDE problem, hence we might want to keep f in DDEIntegrator).

[ranocha]

I also like the idea of using a state.

No, I did not test the influence of inlining of the interpolation functions, I've only played around with ellipsis notation stuff.

[ChrisRackauckas]

Interpolations are no longer inlined since timings show it doesn't do anything.

[ChrisRackauckas]

Total JIT time dropped from 3 seconds to about 1 second now.

I timed the JIT compilation and the majority of the time was in init, then the majority of the rest was in perform_step. Then f is actually mixed in the other places, like addsteps! in savevalues in handle_callbacks! in loopfooter!, and stuff like that. So I don't think to a separate state type would cut more than 20% of compilation time. It would be nice for other reasons.

I think the 1.x compilation changes will capture what we really need, so I am setting this as low priority for now.