# Type-instability because of @threads boxing variables

**URL:** https://discourse.julialang.org/t/type-instability-because-of-threads-boxing-variables/78395
**Category:** Performance
**Tags:** parallel
**Created:** [March 24, 2022, 2:17pm UTC](https://discourse.julialang.org/t/type-instability-because-of-threads-boxing-variables/78395 "2022-03-24T14:17:45Z")
**Posts on this page:** 1
**Showing post:** 5

<div class="post-metadata">

### Author: ![goerch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerch/32/29122_2.png) [@goerch](https://discourse.julialang.org/u/goerch)
#### Post date: [March 24, 2022, 6:19pm UTC](https://discourse.julialang.org/t/type-instability-because-of-threads-boxing-variables/78395/5 "2022-03-24T18:19:35Z")

</div>

> [@lmiq](#):
>
> In my specific case Polyester does not improve the performance (it does remove most allocations).

Hm, I’m wondering why. Do you have any suspicion?

In a recent [thread](https://discourse.julialang.org/t/another-slowdown-when-using-threads-threads/78009/2) I had a pretty big kernel, which was speed up by `Polyester`.

> [@lmiq](#):
>
> But what intrigues me the most is not that threading allocates, but that allocations are detected as if they were occurring in the operations which are local to each thread, while these should be all allocation free (and they are without threading or using Polyester).

I’m not sure if profiling information is always 100% exact (for example I don’t even know if and how macros have to manage `LineNumberNode`s) and believe to have seen some oddities when profiling. Never bothered enough to investigate (especially as I prefer an outdated profiler).

---

_[View the full topic](https://discourse.julialang.org/t/type-instability-because-of-threads-boxing-variables/78395)._