Julia static compilation



I think he’s conflating the idea that you can build executables for MATLAB/Python/R scripts. This is different than static compilation, and akin to bundling libjulia with the script in an executable. I think this is a much easier target, and likely a first goal for a lot of people (at least, a way to do it easily).

There is a package here:

That can do it. But it has some limitations which make it a little difficult.


After reading a few posts on the subject I think people want static compilation for 3 reasons:

1- many julia codes don’t need to be dynamically compiled, a real complete static compilation with optimizations would completely remove the JIT compilation overhead.

2- deploying code and making code distribution easier generating both libs and executables - there are come ways to acomplish these with userimg or buildexecutable. We still get very big programs but I think people have been working in shrinking base which should make it better.

3- some people see generaring libs and execs as methods of hiding proprietary code, I don´t think this is the way… maybe obfuscation is a way to go…

Also, 2 does not solve 1 right? I think it still does not eliminate the need of JIT compilation right before running the code.

Is there a solution to 1 that I have missed?


That’s pretty much it. It just needs to be done.


[double post]


[double post]


Read @joaquimg’s summary above. What you’re asking for isn’t static compilation: it’s compilation of a script to an executable that includes the Julia runtime. This is what MATLAB/Python/R do, which is why the resulting executables are large.

Julia can actually do something else as well: it can generate all of its compiled code and make that executable without Julia. This second case is static compilation, and is more akin to compiling C than it is to compiling MATLAB/Python/R. But it has more restrictions: it cannot do anything that requires the Julia runtime (no @eval and no @generated).

Either way it generates binaries that hide code. But they are different.


What you are responding to is not written by @MatthiasErdmann - it looks like he tried to quote @StefanKarpinski but something went wrong with the discourse formatting (just trying to clear out confusion - this thread is interesting reading).


@joaquimg, to 3: Why do you think generating execs is not a way to hide proprietary code? (I would like to understand your point)


I said:

Firstly, because I am not even close to a specialist in the matter, so I will tell you what I know, that might be imprecise or sometimes wrong.

Given a executable one can extract assembly code, and even convert to C… It will result in a messy code.

Many of the ways people use to put python and R code into execs do not generate assembly code they simply hide the script, so its usually possible to extract the script completely (including comments!). Thus the right thing to do in this case e just code obfuscation and that has nothing to do with static compilation, its just some kind of indirect consequence for languages like C.

I am not sure about the julia process, someone else might it explain and even correct me in whatever mistake I might have made above.

But the 3 topics I presented are independent and people do mix them when talking about static compilation:

  1. remove JIT overhead
  2. make a program more compact easier to distribute
  3. obfuscating the code

In particular, I am more interested in 1 and a little bit in 2 (that can be partially solved by BuildExecutable.jl and the userimg.jl method). 3 might me solved by some routines of replacing words, spacing, tabs, comments etc.


I’m specifically interested in the static compile with minimal runtime usecase. Anyone have any idea how far out that is? 1.0 or post 1.0?


for 3) I have created an issue here:

  1. is actually a pretty nature thing in context of package precompilation, see:


Ability to make proprietary packages is absolutely mandatory for further language adaptation.


While I personally tend to agree with you on some level, can we please make an effort in keeping the tone appropriate for a scientific community and phrase opinions for what they are, opinions, instead of making claims with absolute certainty that no un-clairvoyant being has any business making.


My use case is to run a julia script and exit in under 2 seconds.
My experiments with a fairly simple script[1] is that it takes between 1.5 and 3 seconds.
Is there any way to use any pre-compilation to make this runtimes more consistent?

[1] It just reads a 19K JSON file and writes out a one line file.

Faster/consistent short lived script

That might be related to the slow startup time of Julia compared to e.g. Python

time julia -e ""
real    0m0.323s
user    0m0.356s
sys     0m0.720s

 time python -c ""

real    0m0.018s
user    0m0.012s
sys     0m0.004s


I don’t think static compilation will make startup time any faster.


I just tried to compile the following program with BuildExecutable.jl and julia 0.5 (0.6 failed):

main() = begin end;
$ time ./test_exec/test_exec 

real	0m0.285s
user	0m0.212s
sys	0m0.096s

the same as:

$ time julia-0.5 -e "main()=begin end;main();"

real	0m0.268s
user	0m0.220s
sys	0m0.072s

both runs oscillate around 270ms
julia 0.6 is a little bit faster ~240ms

$ time julia-0.6 -e "main()=begin end;main();"

real	0m0.236s
user	0m0.180s
sys	0m0.072s

but doesn’t beat 0.4:

$ time julia-0.4 -e "main()=begin end;main();"

real	0m0.162s
user	0m0.116s
sys	0m0.064s


What is the dominant cost of startup (assuming there is a single dominant cost)?


Is there any update on this? I’m thinking about implementing some of my current project in Cython, but I would love it if I could use Julia instead. But I need to integrate whatever I do into Python seemlessly (from a user perspective, I’d like them to not know Julia is even there!)


There have been some successful uses of https://github.com/JuliaComputing/static-julia