# Extra allocation with \`T::DataType\`?

**URL:** <https://discourse.julialang.org/t/extra-allocation-with-t-datatype/85930>\
**Category:** Performance\
**Created:** [August 18, 2022, 2:45pm UTC](https://discourse.julialang.org/t/extra-allocation-with-t-datatype/85930 "2022-08-18T14:45:12Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 19, 2022, 7:04am UTC](https://discourse.julialang.org/t/extra-allocation-with-t-datatype/85930/19 "2022-08-19T07:04:54Z")

</div>

Sounds right. Either `@code_native` xor `@btime` is inaccurate, and roughly `@time`ing a non-hoisting loop with no runtime dispatch seems to corroborate `@code_native` here: 0 allocations even over 1e8 iterations.

```julia
julia> foo(Float64,10), foo(10) # compile first
(22026.465794806718, 22026.465794806718)

julia> @time for i in 1:100_000_000
         foo(Float64, i) # non-constant local i prevents hoist
       end
  0.852338 seconds

julia> @time for i in 1:100_000_000
         foo(i) # non-constant local i prevents hoist
       end
  0.848491 seconds

```

Weirdly, in the [other thread](https://discourse.julialang.org/t/recursive-inner-functions-a-thousand-times-slower/85604/7) I linked earlier, this approach corroborated the `@btime` difference instead of the matching `@code_native`/`@code_llvm`. So maybe there should be issues in both base Julia and BenchmarkTools to figure out what is going on.

---

_[View the full topic](https://discourse.julialang.org/t/extra-allocation-with-t-datatype/85930)._