Andrew Kille

@david-pl @Krastanov Additional allocations come from the fact that `recursivecopy` in RecursiveArrayTools calls `deepcopy` by default (https://github.com/SciML/RecursiveArrayTools.jl/blob/e0f1b1ddc98671ade78fb4fd89339224e145fb95/src/utils.jl#L9), which can be problematic in our case. So, if you write ``` RecursiveArrayTools.recursivecopy(x::Ket{B,A})...

It's also now pretty comparable to using `solve` with pure Julia types: ``` const ix = iσx.data schrod_data!(dψ,ψ,p,t) = QuantumOptics.mul!(dψ, ix, ψ) u0 = (↓).data prob_data! = ODEProblem(schrod_data!, u0, (t₀,...

@david-pl If we increase the problem size with `ℋ = SpinBasis(100//1)`, for QO.jl types we get ``` julia> @benchmark sol = solve($prob!,DP5(),save_everystep=false) BenchmarkTools.Trial: 2008 samples with 1 evaluation. Range (min...

@david-pl Here's another decent improvement on allocations and memory, which comes from also defining a `recursivecopy` method for abstract arrays of state vectors: ``` RecursiveArrayTools.recursivecopy(x::AbstractArray{T}) where {T @benchmark sol =...

> @apkille brilliant, thanks for digging into this. I'd love to merge this so we have native DiffEq support ;) Me too. I'm happy to continue this work for other...

> Yeah, there's probably some limitation on what we can do with broadcasting while keeping track of the bases of the state. I agree. Comparing QO types against pure Julia...