# Simulate manual memory management to reduce RAM usage?

**URL:** <https://discourse.julialang.org/t/simulate-manual-memory-management-to-reduce-ram-usage/67281>\
**Category:** General Usage\
**Tags:** garbage-collection\
**Created:** [August 29, 2021, 12:38pm UTC](https://discourse.julialang.org/t/simulate-manual-memory-management-to-reduce-ram-usage/67281 "2021-08-29T12:38:39Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![greatpet](https://avatars.discourse-cdn.com/v4/letter/g/e495f1/32.png) [@greatpet](https://discourse.julialang.org/u/greatpet)\
**Post date:** [August 29, 2021, 12:38pm UTC](https://discourse.julialang.org/t/simulate-manual-memory-management-to-reduce-ram-usage/67281/1 "2021-08-29T12:38:39Z")

</div>

Julia can avoid unnecessary GC by allocating immutable objects on the stack, but I’m wondering if it’s possible to push further: for heap-allocated local objects that do **not** “escape” the function (e.g. returned or passed to another function), is it possible for Julia’s compiler to deallocate the memory as soon as the object is out of scope, i.e. at the end of the function, similar to what happens in C++? If not, is there a reason why this is undesirable in Julia (and GC’ed languages in general)?

Moreover, is it possible to reduce RAM usage by manually deallocating an array `a` by calling `resize!(a,0)` and `sizehint!(a,0)`, before it goes out of scope? Will Julia free the memory immediately following these two commands?

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [August 29, 2021, 12:48pm UTC](https://discourse.julialang.org/t/simulate-manual-memory-management-to-reduce-ram-usage/67281/2 "2021-08-29T12:48:12Z")

</div>

> [@greatpet](#):
>
> is it possible for Julia’s compiler to deallocate the memory as soon as the object is out of scope, i.e. at the end of the function, similar to what happens in C++? If not, is there a reason why this is undesirable in Julia (and GC’ed languages in general)?

It’s not that this is impossible, it’s just an optimization that’s not yet fully done for e.g. arrays. Mutable types that don’t escape already have a similar optimization (though not always applicable and not a guarantee), ~~which is why~~ and immutable types containing references (e.g. `view`s) usually don’t allocate anymore. [It was a big deal when this was done in 1.5.](https://docs.julialang.org/en/v1.5/NEWS/#Compiler/Runtime-improvements) There is talk about more optimizations of that sort though, especially for arrays.

> [@greatpet](#):
>
> Moreover, is it possible to reduce RAM usage by manually deallocating an array `a` by calling `resize!(a,0)` and `sizehint!(a,0)` , before it goes out of scope? Will Julia free the memory immediately following these two commands?

No. `resize!`ing to 0 doesn’t necessarily deallocate the array. You may even inadvertently make it hang around for longer, because you interacted with it. Last I checked, julias’ GC is a generational mark-and-sweep GC, so touching it more often will make the object stay alive for longer, because it’s not checked as often for being alive.

You can try explicitly inserting `GC.gc()` to trigger a sweep, but this is not guaranteed to free memory. The best way to avoid high RAM usage is to not allocate in the first place, use mutating functions that don’t allocate etc.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 12, 2022, 10:32pm UTC](https://discourse.julialang.org/t/simulate-manual-memory-management-to-reduce-ram-usage/67281/3 "2022-11-12T22:32:59Z")

</div>

> [@greatpet](#):
>
> for heap-allocated local objects that do **not** “escape” the function (e.g. returned or passed to another function), is it possible for Julia’s compiler to deallocate the memory as soon as the object is out of scope

Yes, there’s a brand-new package for that, see at:

> [@Avoiding allocations of small but non-trivial arrays (work array alternative?)](https://discourse.julialang.org/t/avoiding-allocations-of-small-but-non-trivial-arrays-work-array-alternative/90084/10):
>
> There’s a brand new package that seems like made for you. It’s probably not yet registered (you can still use/try it), nor announced: In theory Julia could heap-allocate for you and free before exit of barw\_array, but it would be slower. Or allocate on the stack, but it’s limited so dangerous, you don’t know how large the array is going to be, so I doubt that’s a better policy (or check at runtime the size and only stack-allocate if small).

I would try it (in about a week, in case there are bugs). It’s not just for small objects. It’s faster, but actually doesn’t reduce “RAM usage”, just allocation overhead.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [November 13, 2022, 1:17am UTC](https://discourse.julialang.org/t/simulate-manual-memory-management-to-reduce-ram-usage/67281/4 "2022-11-13T01:17:06Z")

</div>

> [@Palli](#):
>
> It’s faster, but actually doesn’t reduce “RAM usage”, just allocation overhead.

Actually, allocating many small non-escaping vectors with julia’s GC will in fact increase memory usage relative to what [Bumper.jl](https://github.com/MasonProtter/Bumper.jl) is doing, because julia’s GC will allocate a bunch of them and then wait until a sufficiently high level of GC pressure accumulates before freeing them.

So instead of just re-using the same memory buffer for each subsequent object like Bumper can do, your memory usage will grow and grow and grow until the GC runs.