# \--track-allocation changes allocation behavior of code?

**URL:** <https://discourse.julialang.org/t/track-allocation-changes-allocation-behavior-of-code/95044>\
**Category:** Performance\
**Created:** [February 22, 2023, 9:25pm UTC](https://discourse.julialang.org/t/track-allocation-changes-allocation-behavior-of-code/95044 "2023-02-22T21:25:34Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ross\_Boylan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ross_boylan/32/9210_2.png) [@Ross\_Boylan](https://discourse.julialang.org/u/Ross_Boylan)\
**Post date:** [February 22, 2023, 9:25pm UTC](https://discourse.julialang.org/t/track-allocation-changes-allocation-behavior-of-code/95044/1 "2023-02-22T21:25:34Z")

</div>

I made some code changes which I guessed would improve memory usage. `@time` shows a huge speedup, \> 10x, and a \>98% reduction in memory used. But when I use `--track-allocation` it seems as if my changes made things much worse.

Are the results of `--track-allocation` sometimes an unreliable guide to the allocation behavior of the code run normally?

Valentin Churavy @vchuravy [wrote](https://github.com/JuliaLang/julia/pull/48070#issue-1515762149)

> The way it [`–track-allocations] functions is to change the emitted LLVM IR to insert code that tracks allocations occuring.  
> This often leads to false-positives since these statements interfere with optimization (in particular escape analysis)

Since the profiles suggest unoptimized code, perhaps my problem is related.

Running Julia 1.8 on Windows. The issue from which the previous quote was drawn indicates 1.9 might behave better.

I would love to provide a small example, but have been unable to isolate the problem. See the discussion [here](https://discourse.julialang.org/t/mysterious-memory-allocation/93431) for how this got started. In brief, I started with lots of memory allocations and reduced many of them to 0 by adding concrete type information to key types in my system. The problems described here occurred when I tried to push things further for remaining hot spots. I added more parameterized types, including parameterized functions, and the total reported allocations went up, including many that had gone to 0.

The code is tricky to trace since it involves calls to functions stored in variables in structures, as well as functions defined on the fly, e.g., `f(z) = ev.f(z, wa)`. `ev.f` is a function stored in a variable, and the definition pulls `wa` from outside the function definition–perhaps what “escape analysis” is about? But when I stepped lower and lower in the call sequence, using `@code_warntype` on each call, the resulting code appeared optimized with stable types. This is consistent with the information reported by `@time`, but not with the results of `--track-allocation`.

The code is executing in a multithreaded context. There is at least one [report](https://discourse.julialang.org/t/can-the-output-of-track-allocation-be-trusted-with-multi-threading-enabled/78744) of strange behavior of `--track-allocation` with multi-threading; it doesn’t look as if the question was ever fully resolved.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [February 22, 2023, 9:40pm UTC](https://discourse.julialang.org/t/track-allocation-changes-allocation-behavior-of-code/95044/2 "2023-02-22T21:40:32Z")

</div>

Yeah. This is a known problem. (and is why using the new allocation profiler is recommended instead).