# Roadmap for small binaries

**URL:** <https://discourse.julialang.org/t/roadmap-for-small-binaries/99266>\
**Category:** Internals & Design\
**Tags:** question\
**Created:** [May 23, 2023, 8:41am UTC](https://discourse.julialang.org/t/roadmap-for-small-binaries/99266 "2023-05-23T08:41:09Z")\
**Posts on this page:** 1\
**Showing post:** 99

<div class="post-metadata">

**Author:** ![thautwarm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thautwarm/32/37760_2.png) [@thautwarm](https://discourse.julialang.org/u/thautwarm)\
**Post date:** [October 31, 2023, 8:58am UTC](https://discourse.julialang.org/t/roadmap-for-small-binaries/99266/99 "2023-10-31T08:58:56Z")

</div>

> [@ToucheSir](#):
>
> But then I’ve also seen articles about reducing binary size for those compilers, so maybe they’ve found a way to do tree shaking or other methods despite having to also deal with dynamic dispatch

Basically, (single) dynamic dispatch itself can be statically compiled with “virtual tables” in .NET CLR/JVM, which can be theoretically much slower than Julia’s multiple dispatch but do not suffer at all from re-compilation and runtime compilation latency.

> [@ToucheSir](#):
>
> Likewise, Dylan exists and is compiled despite having proper multiple dispatch

Dylan’s handling does not really work for Julia due to its lack of support for parametric polymorphism (could be roughly regarded as “generics” tho not precise). Parametric polymorphism is fully supported in Julia.

You could ignore those horrible concepts but have a look at the following code:

```julia
f(x::Vector{T}) where T = ...
f(x::AbstractVector) = ...
f(x::Vector{Int}) = ...

```

The code could demonstrate why we cannot have fast runtime multiple dispatch like that in some LISP dialects. Besides, multiple dispatch **without parametric types** can be easily expressed by looking up dictionaries:

```julia
f(x::VectorInt32) = 1
f(x::VectorInt64) = 2

// f(x) --> method_table[(typeof(x), )](x)
//
// things can be a bit more difficult when supporting subclassing, 
// but still damn easy when comparing to Julia's cases.

```

Actually, parametric polymorphism is powerful, and widely recognized and used in industrial languages (including nearly all C-family languages and static FP languages). However, parametric polymorphism can cause issues such as finding “principal types” or finding “most specific types” or finding most appropriate method – All these “finding \*” must be slow at runtime and cannot be optimized without magic things like a quantum computer.

As a result, a “generic” Julia function could have infinite number of valid compiled (and optimized) specialization, and Julia code that is heavily dynamic cannot compile/optimize them in advanced. So far, Julia usually does a new compilation when finding a required specialization for a “generic” function, this promises the fast execution in the second time but produces severe “time-to-first-plot” latency in some cases.

That’s the whole story.

To solve the issues, the company I’m working for is now concentrating on generating small binaries (both standalone executables and dynamic libraries) for Julia codebase that is “reasonably static”. The project has made progress during mid-2023 and might be available for public use in the early 2024. Our work is based on `code_typed` in a frozen [world age](https://discourse.julialang.org/t/world-age-problem-explanation/9714).

---

_[View the full topic](https://discourse.julialang.org/t/roadmap-for-small-binaries/99266)._