Bug: Abnormal allocation and save_on=false not working

[Lightup1]

Version info

(@v1.7) pkg> status QuantumOptics
      Status `C:\Users\dell\.julia\environments\v1.7\Project.toml`
  [6e0679c1] QuantumOptics v1.0.4

Benchmark of this example:https://docs.qojulia.org/examples/particle-in-harmonic-trap/#Particle-in-harmonic-trap-potential

Result

[0:0.1:pi;]

BenchmarkTools.Trial: 255 samples with 1 evaluation.
 Range (min … max):  15.489 ms … 29.806 ms  ┊ GC (min … max): 0.00% … 10.85%
 Time  (median):     19.298 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   19.599 ms ±  3.689 ms  ┊ GC (mean ± σ):  5.94% ±  7.03%

  █                   
  █▇▄▄▃▃▂▃▃▃▃▃▃▃▂▂▃▃▃▃▃▃▄▄▃▃▃▃▃▃▃▃▃▃▃▃▂▃▃▃▃▃▃▂▃▃▃▃▃▃▁▁▁▁▁▁▁▂▂ ▃
  15.5 ms         Histogram: frequency by time        28.5 ms <

 Memory estimate: 23.25 MiB, allocs estimate: 26305.

[0:0.05:0.5pi;]

BenchmarkTools.Trial: 580 samples with 1 evaluation.
 Range (min … max):  6.856 ms … 13.918 ms  ┊ GC (min … max): 0.00% … 25.52%
 Time  (median):     7.088 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   8.628 ms ±  2.040 ms  ┊ GC (mean ± σ):  6.09% ± 10.34%

  █▅                        ▁▂ ▃▃▁
  ██▆▇▇▄▇▆▇▅▆▇▆▄▆▅▇▆▄▆▅▆▄▇▆▇██████▅▇▄▆▆▇▆▇▆▁▅▆▆▇▅▄▅▆▆█▇▄▆▆▅▄ ▇
  6.86 ms      Histogram: log(frequency) by time     13.7 ms <

 Memory estimate: 10.32 MiB, allocs estimate: 11689.

tout, Ψt = timeevolution.schroedinger(T, Ψ0, H,save_on=false)

BenchmarkTools.Trial: 528 samples with 1 evaluation.
 Range (min … max):  6.698 ms … 71.669 ms  ┊ GC (min … max): 0.00% …  0.00%
 Time  (median):     8.337 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   9.459 ms ±  3.903 ms  ┊ GC (mean ± σ):  6.29% ± 10.74%

   █            
  ▇█▆▃▃▃▃▃▃▃▃▃▃▃▃▃▃▆▄▃▃▃▃▃▃▃▃▃▃▃▃▂▂▃▂▂▂▁▂▁▂▂▂▁▁▂▂▁▁▁▂▂▂▁▁▁▁▂ ▃
  6.7 ms         Histogram: frequency by time        18.9 ms <

 Memory estimate: 10.32 MiB, allocs estimate: 11691.
julia> tout
32-element Vector{Float64}:
 0.0
 0.05
 0.1
 0.15000000000000002
 0.2
 0.25
 0.30000000000000004
 ⋮
 1.25
 1.3
 1.35
 1.4000000000000001
 1.4500000000000002
 1.5
 1.55

After specify save_on=false Still save all results

Reduce save points:

T = [0:0.1:0.5pi;]
@benchmark tout, Ψt = timeevolution.schroedinger(T, Ψ0, H,save_on=false)

BenchmarkTools.Trial: 571 samples with 1 evaluation.
 Range (min … max):  6.455 ms … 16.032 ms  ┊ GC (min … max): 0.00% … 33.98%
 Time  (median):     8.064 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   8.751 ms ±  2.304 ms  ┊ GC (mean ± σ):  6.69% ± 11.82%

  ▅█▄▂                  ▁▃▃▃▁▂▁▂
  █████▅▆▆▅▆▆▇▅▆▆▆▅▇▇▁▆▇█████████▆▆▅▇▅▅▄▅▇▇▅▄▆▅▆█▄▆▅▆▆▆▅▆▅▄▄ ▇
  6.46 ms      Histogram: log(frequency) by time     14.7 ms <

 Memory estimate: 9.93 MiB, allocs estimate: 11251.

Alloc is still high

[Lightup1]

When it comes to my model, the GC time is around 10%.

[Lightup1]

After specify saveat=[], save_on=false start to work. But alloc is still high.

[david-pl]

This is not a bug. We already set save_everystep = false, save_start = false, and save_end = false. Setting save_on = false will probably not have any effect.

For saving we use a SavingCallback with timepoints specified by the list of times you pass in. If you want to reduce that, just pass in less timepoints, e.g. T = [0.0, pi] will only store two points.

Also, make sure to interpolate global variables when benchmarking to avoid measuring false allocations, e.g. @benchmark timeevolution.schroedinger($T, $Ψ0, $H)

[Lightup1]

Dear @david-pl , thanks for your helpful reply, I tried to benchmark again with your tip.

T = [0,0.5pi]
@benchmark tout, Ψt = timeevolution.schroedinger($T, $Ψ0, $H)
BenchmarkTools.Trial: 418 samples with 1 evaluation.
 Range (min … max):   9.050 ms … 18.892 ms  ┊ GC (min … max): 0.00% … 26.99%
 Time  (median):     11.346 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   11.963 ms ±  2.400 ms  ┊ GC (mean ± σ):  5.06% ±  9.29%

   ▅ ▁█▁               
  ▆██████▆▆▄▇▄▄▅▆▄▄▃▂▆▆▆▅▅▄▆▆▄▄▅▃▅▄▄▆▄▃▆▄▅▆▂▃▂▂▃▂▃▄▁▄▁▃▁▃▃▃▁▃ ▄
  9.05 ms         Histogram: frequency by time        17.8 ms <

 Memory estimate: 10.43 MiB, allocs estimate: 11818.

Alloc is still high. Notice that I run it on another machine. Should we reopen the issue?

[Lightup1]

Checked the mul!() of LazyProduct The high alloc is resulted from tmp1 and tmp2.

function mul!(result::Ket{B1},a::LazyProduct{B1,B2},b::Ket{B2},alpha,beta) where {B1,B2}
    tmp1 = Ket(a.operators[end].basis_l)
    mul!(tmp1,a.operators[end],b,a.factor,0)
    for i=length(a.operators)-1:-1:2
        tmp2 = Ket(a.operators[i].basis_l)
        mul!(tmp2,a.operators[i],tmp1)
        tmp1 = tmp2
    end
    mul!(result,a.operators[1],tmp1,alpha,beta)
    return result
end