# Significant allocations with Callbacks (Tsit5)
**URL:** https://discourse.julialang.org/t/significant-allocations-with-callbacks-tsit5/66467
**Category:** Modelling & Simulations
**Tags:** diffeq
**Created:** [August 16, 2021, 7:54am UTC](https://discourse.julialang.org/t/significant-allocations-with-callbacks-tsit5/66467 "2021-08-16T07:54:38Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Amarantine](https://discourse.julialang.org/u/Amarantine)
#### Post date: [August 16, 2021, 7:54am UTC](https://discourse.julialang.org/t/significant-allocations-with-callbacks-tsit5/66467/1 "2021-08-16T07:54:39Z")
I have a reasonably optimized ODE problem where I used callback for terminating the integrator when some values get too large. Without callback I have (43 allocations: 16.23 KiB), and with callback I have (42,065,928 allocations: 3.13 GiB). The callback takes more than 40% of the time (see below).
Here’s a minimal working example using the lorenz problem:
```julia
function lorenz!(du,u,p,t)
du[1] = 10.0*(u[2]-u[1])
du[2] = u[1]*(28.0-u[3]) - u[2]
du[3] = u[1]*u[2] - (8/3)*u[3]
end
u0 = [1.0;0.0;0.0]
tspan = (0.0,100.0)
prob = ODEProblem(lorenz!,u0,tspan)
function condition(out, u, t, integrator)
out[1] = u[1] - 25000;
out[2] = u[2] - 0.2;
out[3] = u[3] - 1.2;
end
function affect!(integrator, index)
if (index == 1)
# ...
# terminate!(integrator);
elseif (index == 2)
# ...
# terminate!(integrator);
elseif (index == 3)
# ...
# terminate!(integrator);
end
end
cellFate = VectorContinuousCallback(condition, affect!, nothing, 3, save_positions=(false, false));
@btime solve(prob,Tsit5()) # no callback
@btime solve(prob,Tsit5(), callback=cellFate) # with callback
```
In this example, without callback it takes 689.839 μs (11748 allocations: 1.37 MiB), and with callback it takes 2.161 ms (24628 allocations: 2.34 MiB). I don’t understand why the callback function could have so many allocations.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [August 16, 2021, 3:36pm UTC](https://discourse.julialang.org/t/significant-allocations-with-callbacks-tsit5/66467/2 "2021-08-16T15:36:45Z")
Yeah, that looks like a performance bug, and it turned out to be a journey.
[https://github.com/SciML/SciMLBase.jl/pull/99](https://github.com/SciML/SciMLBase.jl/pull/99)
[https://github.com/SciML/DiffEqBase.jl/pull/705](https://github.com/SciML/DiffEqBase.jl/pull/705)
[https://github.com/SciML/OrdinaryDiffEq.jl/pull/1473](https://github.com/SciML/OrdinaryDiffEq.jl/pull/1473)
See the caveats of the last PR though… still working through that.
---
### Author:  [@mauro3](https://discourse.julialang.org/u/mauro3)
#### Post date: [August 16, 2021, 5:30pm UTC](https://discourse.julialang.org/t/significant-allocations-with-callbacks-tsit5/66467/3 "2021-08-16T17:30:18Z")
Maybe you can hack it by using `isoutofdomain`: let that function return true when the solution goes beyond where you want to terminate. The solver should then (after reaching the minimum step) stop.
Although, Chris is usually super fast with fixing those issues… so you got to be quick!
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [August 16, 2021, 5:32pm UTC](https://discourse.julialang.org/t/significant-allocations-with-callbacks-tsit5/66467/4 "2021-08-16T17:32:19Z")
This issue is weird though, did you see the gif?
The way to get rid of the allocations requires (currently) that you use Revise and reevaluate one of the functions in the package (without changing it). I gotta say, this is a first for me 😅
---
### Author:  [@ranocha](https://discourse.julialang.org/u/ranocha)
#### Post date: [August 16, 2021, 5:58pm UTC](https://discourse.julialang.org/t/significant-allocations-with-callbacks-tsit5/66467/5 "2021-08-16T17:58:40Z")
> [@ChrisRackauckas](#):
>
> The way to get rid of the allocations requires (currently) that you use Revise and reevaluate one of the functions in the package (without changing it).
I observed the same behavior before, see [`prolong2mortars!` with `P4estMesh` allocates sometimes · Issue #628 · trixi-framework/Trixi.jl · GitHub](https://github.com/trixi-framework/Trixi.jl/issues/628#issuecomment-897489906) for an analysis (and a dirty workaround in the PR closing that issue). The basic reason there is an inference failure involving recursive calls (and splatting of tuples in this case).