# Inconsistency in Allocs reported by track-allocs vs BenchmarkTools

**URL:** <https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166>\
**Category:** General Usage\
**Tags:** performance, memory-allocation\
**Created:** [June 24, 2024, 10:57pm UTC](https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166 "2024-06-24T22:57:38Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Spuriosity1](https://avatars.discourse-cdn.com/v4/letter/s/eb9ed0/32.png) [@Spuriosity1](https://discourse.julialang.org/u/Spuriosity1)\
**Post date:** [June 24, 2024, 10:57pm UTC](https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166/1 "2024-06-24T22:57:38Z")

</div>

I have tried to write a low-overhead function that adds a number of Lorentzian peaks to a grid of intensities. When run under @benchmark, it reports “0 allocations”, but when run within my program, I get a large number of allocations reported inside this functions:

```julia
        - # puts Lorentzians of weights Snm at energies Enm
        - function broadened_peaks!(
        - Sqω::Union{Vector{ComplexF64}, Vector{Float64}},
        - Snm::Union{Matrix{ComplexF64}, Matrix{Float64}},
        - Enm::Matrix{Float64},
        - Egrid::Vector{Float64},
        - dE::Float64
        - )
        - 
  4476632 for (E,S) in zip(Enm,Snm)
192964896 for (i,e) in enumerate(Egrid)
690203472 Sqω[i] += S*Lorentzian(e-E, dE)
884581976 end
 12304264 end
        - end

```

Why are such high allocations being reported here?

---

<div class="post-metadata">

**Author:** ![abraemer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abraemer/32/51403_2.png) [@abraemer](https://discourse.julialang.org/u/abraemer)\
**Post date:** [June 25, 2024, 6:18pm UTC](https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166/2 "2024-06-25T18:18:57Z")

</div>

This is likely due to compilation.

That’s why the [manual recommends](https://docs.julialang.org/en/v1/manual/profile/#Line-by-Line-Allocation-Tracking) running the workload once and then using `Profile.clear_malloc_data()` to reset the counters.

---

<div class="post-metadata">

**Author:** ![Spuriosity1](https://avatars.discourse-cdn.com/v4/letter/s/eb9ed0/32.png) [@Spuriosity1](https://discourse.julialang.org/u/Spuriosity1)\
**Post date:** [June 25, 2024, 11:18pm UTC](https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166/3 "2024-06-25T23:18:45Z")

</div>

Sorry, I don’t understand - shouldn’t compilation be a ‘run once’ operation? Does this mean that for whatever reason, broadened\_peaks! is being recompiled at every iteration?

For further context, this was not run in the REPL - there is a driver script that in essence just calls this function several million times. I also tested with different numbers of repetitions - the number of allocations changes depending on the number of repetitions.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [June 25, 2024, 11:48pm UTC](https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166/4 "2024-06-25T23:48:22Z")

</div>

Are you sure BenchmarkTools calls your function with the same combination of parameter types as when executed by your driver?

---

<div class="post-metadata">

**Author:** ![Spuriosity1](https://avatars.discourse-cdn.com/v4/letter/s/eb9ed0/32.png) [@Spuriosity1](https://discourse.julialang.org/u/Spuriosity1)\
**Post date:** [June 26, 2024, 12:16am UTC](https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166/5 "2024-06-26T00:16:18Z")

</div>

I’ve tested for all four possible combinations of types under BenchmarkTools - one gives InexactError, the other three show zero allocations.

To be extra sure, I rewrote two methods without using any Union types, several billion allocations are still being associated with this function call.

````julia
        - function broadened_peaks!(
        - Sqω::Vector{ComplexF64},
        - Snm::Matrix{ComplexF64},
        - Enm::Matrix{Float64},
        - Egrid::Vector{Float64},
        - dE::Float64
        - )
        - 
  6748880 for (E,S) in zip(Enm,Snm)
315413912 for (i,e) in enumerate(Egrid)
1343077008 Sqω[i] += S*Lorentzian(e-E, dE)
1565108288 end
 20662600 end
        - end

        - 
        - # puts Lorentzians of weights Snm at energies Enm
        - function broadened_peaks!(
        - Sqω::Vector{Float64},
        - Snm::Matrix{Float64},
        - Enm::Matrix{Float64},
        - Egrid::Vector{Float64},
        - dE::Float64
        - )
        - 
  2891376 for (E,S) in zip(Enm,Snm)
133055928 for (i,e) in enumerate(Egrid)
389021376 Sqω[i] += S*Lorentzian(e-E, dE)
710797752 end
  8618144 end
        - end

       ```
````

---

<div class="post-metadata">

**Author:** ![abraemer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abraemer/32/51403_2.png) [@abraemer](https://discourse.julialang.org/u/abraemer)\
**Post date:** [June 26, 2024, 5:19am UTC](https://discourse.julialang.org/t/inconsistency-in-allocs-reported-by-track-allocs-vs-benchmarktools/116166/6 "2024-06-26T05:19:49Z")

</div>

The allocations are likely caused by `track-allocations`. From the manual I linked above:

> `--track-allocation` changes code generation to log the allocations, and so the allocations may be different than what happens without the option. We recommend using the [allocation profiler](https://docs.julialang.org/en/v1/manual/profile/#allocation-profiler) instead.

The loop constructs rely heavily on inlining and subsequent compiler optimizations to avoid allocations. I think `track-allocations` might just hinder that with the extra code that tries to track allocations per line.