# Do Garbage Collectors necessarily make code slow?

**URL:** <https://discourse.julialang.org/t/do-garbage-collectors-necessarily-make-code-slow/97902>\
**Category:** Offtopic\
**Tags:** garbage-collection\
**Created:** [April 24, 2023, 10:55am UTC](https://discourse.julialang.org/t/do-garbage-collectors-necessarily-make-code-slow/97902 "2023-04-24T10:55:56Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [April 27, 2023, 4:25am UTC](https://discourse.julialang.org/t/do-garbage-collectors-necessarily-make-code-slow/97902/22 "2023-04-27T04:25:50Z")

</div>

The compiler is getting better. There was a big improvement in Julia 1.5 for structs containing heap allocated objects no longer themselves always being heap allocated (e.g. `SubArray`s created from `view`s), but things like non-escaping `MArray`s were non(-heap) allocating for a very long time.  
The difficulty is the non-escaping part, which can eventually be made easier with escape analysis…

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [April 27, 2023, 12:40pm UTC](https://discourse.julialang.org/t/do-garbage-collectors-necessarily-make-code-slow/97902/23 "2023-04-27T12:40:31Z")

</div>

> [@Elrod](#):
>
> `FastBroadcast.jl` gets around this by special casting the case where all sizes are equal, so that no array is actually broadcast. Thus, a fast loop for this case is always generated.

This should really get upstreamed to Base, not just because it’s a runtime improvement but also because it’s a non-trivial compile time improvement in some cases.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [April 27, 2023, 2:11pm UTC](https://discourse.julialang.org/t/do-garbage-collectors-necessarily-make-code-slow/97902/24 "2023-04-27T14:11:42Z")

</div>

In updating the loop unswitching pass for the new pass manager, LLVM also broke it for some important Julia cases that aren’t tested within LLVM itself.  
This is one of the things blocking an LLVM upgrade at the moment.  
Test added to catch that in Julia:

> <https://github.com/JuliaLang/julia/pull/49317>
>
> This tests that basic broadcasting operations (outer/inner products) do end up v…ectorizing after the LLVM pipeline.
> 
> @gbaraldi This will probably block LLVM 15 due to https://discourse.llvm.org/t/newpm-loop-unswitch-regression-from-legacy-pm-to-new-pm/69823 and https://reviews.llvm.org/D124376

Aside from all our efforts on improving SciML runtime and compile times, it was funny that it also came up recently as blocking a major upgrade, thanks to relying on the fickle compiler.

The thing about broadcasting vs loops is that broadcasting is better for generic code, where you may have some sort of GPUArray or a SparseArray, so we really don’t want to discourage using broadcasting.  
I wish broadcasts didn’t broadcast. Instead, we have to make the best out of these semantics that we can.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [April 27, 2023, 2:19pm UTC](https://discourse.julialang.org/t/do-garbage-collectors-necessarily-make-code-slow/97902/25 "2023-04-27T14:19:14Z")

</div>

> [@Elrod](#):
>
> I wish broadcasts didn’t broadcast. Instead, we have to make the best out of these semantics that we can.

I many times wish `.` defaulted to map and it needed an `@broadcast` or something to mean broadcast.

[Previous page](https://discourse.julialang.org/t/do-garbage-collectors-necessarily-make-code-slow/97902.md?page=1)