I just tried using PackageComipler on Plots.jl. With precompiled images, I got
julia> @time using Plots
0.891786 seconds (1.26 M allocations: 59.289 MiB, 16.97% gc time)
julia> @time (p = plot(rand(5), rand(5)); display(p))
19.150645 seconds (23.79 M allocations: 1.167 GiB, 3.50% gc time)
Without it, I got
julia> @time using Plots
22.850512 seconds (26.91 M allocations: 1.375 GiB, 3.72% gc time)
julia> @time (p = plot(rand(5), rand(5)); display(p))
25.178778 seconds (28.32 M allocations: 1.400 GiB, 2.38% gc time)
The loading time certainly improved significantly, but not so much for the first plotting time. Is this normal?
1 Like
Following the instructions for creating a Plots.jl sysimage, I was able to reduce my load time significantly:
time julia -e "using Plots; p = plot(rand(5), rand(5)); display(p)"
23.78s user 0.75s system 75% cpu 32.647 total
time julia --sysimage sys_plots.so -e "using Plots; p = plot(rand(5), rand(5)); display(p)"
0.41s user 0.20s system 67% cpu 0.908 total
Are you plotting in the terminal, or Atom/VSCode? If it’s the latter, try this workaround. IDEs require extra machinery to display plots, and PackageCompiler needs to see that machinery if it’s to be compiled into a sysimage.
1 Like
I see what is the problem. I didn’t compile the image correctly. Now it’s now fast.
1 Like
Two questions… If the package is baked into your system image 1) do you not have to add Plots anymore? i.e. it won’t be part of your environment?
and 2) what happens when there is a new update release? Can you run pkg> up or does a new image have to be compiled?
1 Like
I am interested in these questions too…
The docs explain that one of the main downsides of using PackageCompiler is that you cannot up a package that’s included in the sysimage anymore, i.e. it is frozen at whatever version you included in the image.
3 Likes
I tried the procedure in the documentation but when I run:
using PackageCompiler
create_sysimage(:Plots, sysimage_path="sys_plots.so", precompile_execution_file="precompile_plots.jl")
I get:
ERROR: UndefVarError: create_sysimage not defined
Stacktrace:
[1] top-level scope at REPL[5]:1
Some changes in the API ? (I installed PackageCompiler v0.6.5)
EDIT: I see that PackageCompiler is at v 1.1… I just added to a Julia1.3 instance today, it installed the v0.6.5 not the v1.1…
How can I know what is it blocking the installation of the latest version ?
I think you can try to add a specific version of PackageCompiler like this –How to install a specific version of a package with Pkg.add("...")
It requires Julia 1.3.1.
The newest release is 1.4.1. You should always use the latest release.
2 Likes
Some how it is still much slower in REPL
(base) xing@MAT-WL-xinca341:PackageCompile$ time julia -e "using Plots; p = plot(rand(5), rand(5)); display(p)"
real 0m48.484s
user 0m47.686s
sys 0m1.032s
(base) xing@MAT-WL-xinca341:PackageCompile$ time julia --sysimage sys_plots.so -e "using Plots; p = plot(rand(5), rand(5)); display(p)"
real 0m0.695s
user 0m0.513s
sys 0m0.726s
(base) xing@MAT-WL-xinca341:PackageCompile$ julia --sysimage sys_plots.so
julia> @time using Plots
0.746027 seconds (1.26 M allocations: 59.292 MiB, 1.40% gc time)
julia> @time (p = plot(rand(5), rand(5)); display(p))
14.563074 seconds (20.60 M allocations: 1.022 GiB, 5.75% gc time)
Do you load packages in startup.jl?
Yes, OhMyREPL and Revise.
Okay, then you are in the territory of invalidations (see https://github.com/JuliaLang/www.julialang.org/pull/794 for a WIP blogpost about this exact problem). My guess is that this will have quite a bit of focus in the upcoming months so hopefully should improve.
4 Likes
OK. I have also compiled OhMyREPL following the instruction here PackageCompiler.jl/ohmyrepl.md at master · JuliaLang/PackageCompiler.jl · GitHub.
So it’s not a problem anymore.
It seems that it’s Revise slowing things done. I will just remove it from startup.jl.