# Yet another question about Julia's high RAM usage

**URL:** <https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693>\
**Category:** Internals & Design\
**Tags:** memory\
**Created:** [July 14, 2025, 8:17am UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693 "2025-07-14T08:17:15Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [July 21, 2026, 7:44pm UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693/21 "2026-07-21T19:44:33Z")

</div>

> [@jakobnissen](#):
>
> But aside from the direct quote, it’s also obvious from the design of the language. Julia is an experiment in what happens if you bring _everything_ to the runtime (even a full BLAS with no opt-in!), and do _all of the compilation_. Specialize on every argument, make every function generic on every argument, make functions and closures their own type. In [the generics dilemma](https://research.swtch.com/generic), Julia chose the C++ approach and then pushed it to the extreme because C++'s compile times weren’t, apparently, dissuasive enough.

Sounds like this would be a much smaller problem if Julia wasn’t JAOT compiled.

---

<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:** [July 21, 2026, 8:37pm UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693/22 "2026-07-21T20:37:30Z")

</div>

Isn’t it the other way around? The way I see it, the difficulty with this approach is exactly that if you want to fully AOT compile, you have to find, prepare, compile and save every possible reachable specialization.

---

<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:** [July 22, 2026, 4:24am UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693/23 "2026-07-22T04:24:33Z")

</div>

Yes, AOT compilation needs to cover “everything”, but that isn’t often much compared to a baseline runtime, and there are more factors in what “everything” is. I asked this question in the first place because I didn’t (and still don’t have a way to) know much about how a Julia session allocates source code, docstrings, types, method table, compiled code, standard libraries, the compiler, BLAS buffers, etc. AOT-compiled binaries don’t carry all of that, and it’d be nice to have some idea what is trimmable.

> [@jakobnissen](#):
>
> Specialize on every argument

There are exceptions to the rule: `Function`, `Type`, `Vararg` arguments needs method parameters, and `@nospecialize` opts out. But nonspecialized arguments and runtime dispatch have a higher cost and unbounded extent in Julia where functions don’t have consistent return types and are dispatched over multiple arguments; one consequence is trimmed JuliaC being limited to a “static” subset that is less dynamic than many statically typed languages.

---

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [July 22, 2026, 11:25pm UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693/24 "2026-07-22T23:25:25Z")

</div>

> [@Mason](#):
>
> Isn’t it the other way around? The way I see it, the difficulty with this approach is exactly that if you want to fully AOT compile, you have to find, prepare, compile and save every possible reachable specialization.

Fair enough; I was thinking about the TTFP issue rather than binary sizes.

---

<div class="post-metadata">

**Author:** ![bensetterholm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bensetterholm/32/12792_2.png) [@bensetterholm](https://discourse.julialang.org/u/bensetterholm)\
**Post date:** [July 24, 2026, 12:04pm UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693/25 "2026-07-24T12:04:26Z")

</div>

> [@Oscar\_Smith](#):
>
> no one on a personal computer has \<8gb of ram.

It’s all fun and games until you try to deploy your “simple” program to a Raspberry Pi and regret your decision of buying the 2 GB model…

---

<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:** [July 24, 2026, 2:52pm UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693/26 "2026-07-24T14:52:34Z")

</div>

> [@Benny](#):
>
> 1. an OpenBLAS implementation that preallocates buffers to accelerate matrix multiplication that cannot be removed from `Base`

Well, it can be removed from Base, a lot can be removed, I’ve experimented with that:

> <https://github.com/PallHaraldsson/julia/pull/4>
>
> See: https://github.com/JuliaLang/julia/issues/50833#issuecomment-1671906912
> 
> …It's 22% faster startup because the sysimage is 33% smaller.
> 
> With a minor breaking change it would be 30.2% faster and 37.5% smaller.

> It’s 22% faster startup because the sysimage is 33% smaller.

> [@bensetterholm](#):
>
> It’s all fun and games until you try to deploy your “simple” program to a Raspberry Pi and regret your decision of buying the 2 GB model…

It helps to make the sysimage smaller. You don’t need to use my fork of Julia, just the sysimage it generates. It’s entirely supported to use Julia with alternative sysimage with `-J, --sysimage <file>` Start up with the given system image file

Startup of Julia (and memory use) is O(n) in sysimage size, if I recall, roughly. While [Open]BLAS can be dropped, helpful for some users, it only allocates virtual memory, no cost until used.

> [@ParadaCarleton](#):
>
> Sounds like this would be a much smaller problem if Julia wasn’t JAOT compiled.

And that’s an option now:

> [@Joovy - Faster compilation](https://discourse.julialang.org/t/joovy-faster-compilation/137945/1):
>
> Joovy uses three tiers. Tier 0 is basically not-compiled. Fast to load, but slow to execute.

More Python like then. you would also set -O0 before, but then for all code.

---

<div class="post-metadata">

**Author:** ![Jake](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jake/32/46007_2.png) [@Jake](https://discourse.julialang.org/u/Jake)\
**Post date:** [July 24, 2026, 5:44pm UTC](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693/27 "2026-07-24T17:44:29Z")

</div>

> [@bensetterholm](#):
>
> It’s all fun and games until you try to deploy your “simple” program to a Raspberry Pi and regret your decision of buying the 2 GB model…

I just used `top` on my 8 GByte RPI 4. The data acquisition takes 1.6 GB (20% CPU) and processing takes 1.9 GB (100 % CPU). Without additional cooling it is probably throttled due to CPU temperature.

[Previous page](https://discourse.julialang.org/t/yet-another-question-about-julias-high-ram-usage/130693.md?page=1)