If I create a binary file using packagecompliler.jl, will the code be as (or almost as) fast as a C++ binary file?
Or are there any hidden performance issues?
If I use any external library, will the size of the binary file get very big as is can happen while using PyInstaller in Python?
Hi @boroboro77. Welcome to the julia discourse! If you create an executable using PackageCompiler, then it may be as fast as a C++ program that does the same thing, but there are many factors affecting whether or not that will be the case. Obviously the speed depends on the quality of the code you write. If you write slow code (for example linear algebra or array processing code with many unnecessary allocations) then compiling it into a binary with PackageCompiler won’t magically make it fast.
I think a better way to think about what PackageCompiler can do is to consider how a program compiled into a standalone app with PackageCompiler will run compared to running the same code as a script launched from the command line.
If you run
$ julia my-app.jl
from the command line then a few things need to happen:
- The julia runtime needs to start. Last I heard/checked this was about 0.1s on an average spec laptop but don’t quote me on that. It’s been getting better with each release.
- The first part of the compilation process has to happen. Very roughly speaking, this is the amount of time it takes to run all the
using <package-name> statements in your app. Put another way, it’s the part of the compilation process that can occur without knowing the exact runtime types going through your program.
- The second part of the compilation has to happen and then your code has to run.
PackageCompiler won’t help with 1. Your compiled app will still need to load the julia runtime. Loading a very simple compiled from C++ program will not have as much overhead as loading the julia runtime. So for very short running programs you won’t be able to compete with the native C++ app but this difference will be negligible for programs that take more than a few seconds to run.
If 2 is a big bottleneck in your julia code then PackageCompiler will help a lot.
3 is where it gets a bit more subtle. A naive use of PackageCompiler will not help here. For example, if you do
y = MyPackage.foo(x)
and run package compiler without using a precompile execution file, then you’ll save the overhead of loading
MyPackage but calling
MyPackage.foo(x) will run in the amount of time it takes to run the first time you run it in a regular julia session. However, if you have a well written precompile execution file then your PackageCompiler accelerated app should run
MyPackage.foo(x) without the first run overhead. See the PackageCompiler docs for more info.
As for the size of the binary file, it will unfortunately be pretty big. Even for a trivially simple application the julia runtime has to be bundled as part of your app so the minimum size of a PackageCompiler app is ~300MB.
Thank you very mucht. This is was I expected. It’s not a dealbreaker using julia, but i won’t use it to creat executables.
Does the design of Julia allow us to do this one day in a better way?
My dream would be that you just compile a code like you would do in C++ and you get a very lightweight file (depending on the project obviously).
I don’t know enough to speculate in any detail on the extent of what might be possible in the future. As far as I know it should be possible to make julia standalone apps a lot smaller than they are now but getting them as small as native compiled apps would be tough. The lower hanging fruit (which is to say easier than other things but still not necessarily easy) seem to various versions of purging unused libraries from the baggage that comes along with the julia standard libs. For example, if you make a relocatable hello world app in julia you currently end up bundling a bunch math and other libraries along with it. But once you strip out standard lib stuff, you still need the core of the julia runtime and I don’t know how you shrink that down enough to make a truly lightweight app.