Christopher Rackauckas

Yup, good suggestion! Reopened and re-titled along the lines of that.

>At the end of perform_step, do integrator.last_callback = 0, and then while handling callbacks, if any of them trigger, update integrator.last_callback. (Though continuous and discrete callbacks are handled separately, so...

The issue was confirmed to be event handling misses due to the large number of jumps. This was verified by checking `jump_u` for negatives. It's a hard issue to fix...

>Second, the functor setup incurs an overhead and I'm seeing a 100% slowdown on average. That seems extreme. Is it strictly typed?

Do you have an example you can share that has this amount of slowdown?

For userdata, why not pass a mutable struct for the mutable data? The dictionary will be slower.

This could make a good GSoC project.

For second order methods, our current state is the form http://docs.juliadiffeq.org/latest/types/dynamical_types.html http://docs.juliadiffeq.org/latest/solvers/dynamical_solve.html The solvers technically let you give it a `t` argument, so you can define a partitioned ODE from...

Transferred to DiffEq since it seems to be a downstream issue with the similar overload.

Thank you for the issue. This is a very nice example and it should be easy to find out what's going on from it.