Optimizations for VRDirectCB

[ChrisRackauckas]

VRDirectCB needs some code optimizations. Clear things to do:

• Create a separate FunctionWrapper mode, i.e. VRDirectCBFW which wraps things in FunctionWrappers for cases with large numbers of jumps
• Check https://github.com/SciML/JumpProcesses.jl/pull/477/files#diff-ef724e728ebe5838ea90cbda75a1e828afc91def61764cfec717b4ba24b7580bR174-R177 constant props
• Create flamegraphs to showcase other potential performance bottlenecks
• Setup a benchmark in SciMLBenchmarks (i.e. finish Benchmarking Variable Rate Aggregator SciMLBenchmarks.jl#1230)
• Change VRDirectCB to the default when demonstrated as more efficient.
• Make sure everything is type stable with regards to the VRJs and rate/affect evaluation in the no FunctionWrapper case.
• Reuse last cur_rates evaluation from the condition in the affect if it is at the correct time (i.e. if the quadrature uses the endpoints).
• See if additional @inbounds decorators improves performance
• use preallocated u_tau instead of out-of-place evaluation.
• Think about what order / type of quad rule to use. Why are we using the 4-point Gauss-Legendre quadrature currently? (For example, we could use a rule that includes endpoints to avoid recalculating the cumulative rate sum at the final point.)

[ChrisRackauckas]

@sivasathyaseeelan

[isaacsas]

A secondary optimization that may be important to actually get better performance than the old approach we used is to play with the quadrature order. The higher it is the more times we need to evaluate all the rates each call to the condition vs. the less accurate the integral evaluation is for lower orders, so there may be a sweet spot that optimizes performance.

[ChrisRackauckas]

We will get a Gauss-Kronrod version rather soon, and that would be a nice error controlled way.