# Could Someone Explain To Me the Desire for Small Julia Binaries?

**URL:** <https://discourse.julialang.org/t/could-someone-explain-to-me-the-desire-for-small-julia-binaries/96484>\
**Category:** General Usage\
**Tags:** question\
**Created:** [March 22, 2023, 10:55pm UTC](https://discourse.julialang.org/t/could-someone-explain-to-me-the-desire-for-small-julia-binaries/96484 "2023-03-22T22:55:15Z")\
**Posts on this page:** 1\
**Showing post:** 19

<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:** [March 24, 2023, 12:23pm UTC](https://discourse.julialang.org/t/could-someone-explain-to-me-the-desire-for-small-julia-binaries/96484/19 "2023-03-24T12:23:51Z")

</div>

> [@lrnv](#):
>
> like what `Rcpp` does ? That would be terrific. The current possibilities with `JuliaCall`, although they have the merit to even exist, are not as practical…

I see for JuliaCall:

> SystemRequirements Julia \>= 0.6.0, RCall.jl

So I assume RCall.jl is used. I’m not sure but I think it allows calling R in the same process. R is GPL, so that means your whole program is GPL. If you’re trying to get out of that, then Rcpp doesn’t help you either. So what’s the point of (small) binaries for you? [It’s already a problem to distribute GPL-free R-only binaries and/or small R binaries, seem to be 77 MB+.]

In some few cases (small) binaries can help, but in very many cases distributing source code is ok (and/or sysimage), and startup as fast. And the source code can be way smaller than the binary…

> [@lmiq](#):
>
> Distributing Julia programs as Linux applications through standard package managers. If every app takes 100+ Mb that’s not feasible.

That doesn’t seem like a problem. You would do same as with Python, you distribute the (likely smaller) source code, and let the package depend on julia (rather large but one-time shared cost) runtime (apt or snap or whatever) package…

> [@adienes](#):
>
> Binary size affects startup time if your jobs are containerized

Again not a problem (e.g. do most Python users compile in that setting?). It seems like a lot of the fixed overhead (of the runtime and LLVM) could be shared across containers? Startup speed doesn’t need to be large, even with source code (assuming precompiled), getting better in 1.9, or if you can compile your source code (partially or fully) to a sysimage.

> [@Fastest Julia startup challenge/smallest sysimage](https://discourse.julialang.org/t/fastest-julia-startup-challenge-smallest-sysimage/95389):
>
> @vchuravy or anyone who would like to help in the challenge. sys.so shrinks from 173M to 96M With julia --startup-file=no startup time improves to 77ms from 127ms on my machine That’s 39% faster startup, with a 44% smaller sysimage, so to a first approximation, the startup time of Julia scales linearally with the sysimage size. With that speedup I think it would really help Julia make top spot at the Debian benchmark game. My only requirement is that the sysimage/julia be usable for that…

---

_[View the full topic](https://discourse.julialang.org/t/could-someone-explain-to-me-the-desire-for-small-julia-binaries/96484)._