# Poor performance of garbage collection in multi-threaded application

**URL:** https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493
**Category:** Julia at Scale
**Tags:** garbage-collection
**Created:** [January 31, 2022, 9:47am UTC](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493 "2022-01-31T09:47:08Z")
**Posts on this page:** 1
**Showing post:** 22

<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: [February 3, 2022, 10:57pm UTC](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493/22 "2022-02-03T22:57:09Z")

</div>

It is more of an intrinsic problem. In the (g)olden days they used compacting garbage collection to fight fragmentation, but this is not an option here AFAIU (or are we?). You’ll probably have to identify the critical paths of your application and use an adequate preallocation or arena allocation strategy.

Edit: just [looked](https://discourse.julialang.org/t/is-the-garbage-collector-non-compacting/16335) it up, here another [link](https://discourse.julialang.org/t/details-about-julias-garbage-collector-reference-counting/18021).

> [@racinmat](#):
>
> Is there any way to defragment memory if it’s already fragmented, or is it tied to how large chunks of memory and where in the code do I allocate them?

No and yes.

---

_[View the full topic](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493)._
