[ANN] Fezzik.jl : Brute force sysimg building for Julia

announcement
#1

Provides a hassle-free way of generating a snappy first use experience with Julia , without going into technicalities, I wrote this package to help co-workers who uses Julia for their everyday reaserch

Fezzik

Make Julia fast again

Installation

using Pkg
pkg"add https://github.com/TsurHerman/Fezzik"

Usage

one time setup

using Fezzik
Fezzik.auto_trace()

enables automatic tracing of compiler activity through adding itself
to the startup.jl file.
After this phase you’ll need to re-launch julia , work a little bit to let Fezzik trace your routine and then:

Fezzik.brute_build_julia()

builds a new julia system image with all the traced statements baked into the system image resulting in a much smoother experience with julia for the small price of slightly increased loading time, If you are working with Juno’s cycler mode then this price is nicely hidden from you.

using Fezzik
blacklist("Mypkg1","Mypkg2")

A persistant blacklist that prevents Fezzik from precompiling statements from your currently in-development modules, as baking them into the sysimg prevents you from seeing changes you make to the code

using Fezzik
blacklist()

call blacklist with no arguments to see all blacklisted modules

using Fezzik
whitelist("Mypkg1","Mypkg2")

make white what was once black

Fezzik.auto_trace(false)

remove itself from the startup.jl and deletes previous traces

trace logs can be found by running the following command

abspath(dirname(pathof(Fezzik)),"../","traces") |> edit

PyPlot

to enable PyPlot showing properly after it was baked into the sytem image
add

PyPlot.ion()

to your startup.jl

Revert

every now and then you’ll want to start over , just call

Fezzik.revert()

to go back to the beginning

17 Likes
#2

Available on GitHub.

#3

You ARE the brute squad!
:muscle::+1:

1 Like
#4

How does it interact with package updates?

#5

Great package, I did enjoy that kind of API :slight_smile:

That should likely come from creating a new system image from scratch, missing AOT compiled functions that come with the standard system image. If you use PackageCompiler.compile_incremental(nothing, trace_file.jl), this should include them! Make sure though, that you don’t compile from an image that already got compiled incremental - that seems to be problematic (not sure if impossible, or just very easy to break).

#6

It does not, if a package was baked in and you updated it , you’ll need to revert and start again

#7

This is what Fezzik does(thanks for taking care of package compiler) , hmm I use it to build incrementally a few times with no problem , and if things break … go back to the beginning.
There is another interesting function, sysimg_size() which gives you the current sysimg size … you can see it rise in the numbers after every build.

#8

It does not, if a package was baked on and you updated it , you’ll need to revert and start again

there should be an relatively easy hack to teach revise to just compile the diff on startup… Likely needs some work to make Revise talk with PackageCompiler/Fezzik…

This is what Fezzik does

Ah great :slight_smile: Seemed like it eliminated most load time regression for my cases…