sysimage with `Plots.jl` compiled is slow in Atom/Juno IDE

[hhaensel]

When using a sysimage with Plots.jl compiled as described in the new docs, the display of plots in Atom/Juno is slow.
While the timing of both loading using Plots and plotting is nominally fast as expected according to @time, it takes approx. 2 seconds for the plot to appear.
When modifying the call to

p = plot(rand(5), rand(5));
display(p)

The plot appears immediately, but the prompt only returns after 2 seconds delay.

In a standalone REPL this problem does not appear.

The issue has been reproduced on two different Windows 10, 64-bit machines. According to @KristofferC (see #337), the problem does not occur on a Mac.

my machine:
Windows 10 64bit
Atom 1.44.0
julia-client 0.12.2

[AndiMD]

I have a similar problem. When Revise.jl is loaded in my startup file (without Atom), plotting is slow.

Does Atom by default load Revise.jl? I tried push!(Revise.dont_watch_pkgs,:Plots) but it did not make a difference.
I'm on Linux64, tried both Julia 1.3.1 and 1.4-rc2

[francescoalemanno]

@hhaensel have you tried doing the following:

in Atom , go to Juno settings, search for the option to add julia startup arguments and add something like:

--trace-compile="/home/me/extracompilestmts.jl",--sysimage=mysysimage_withPlots.so

restart Atom, open the repl in atom and use generate some plots.
keep atom open and do not restart julia.

Go to your home directory and copy the file "extracompilestmts.jl" somewhere else, now you can close Atom.

Now all that is left to do is run julia with the Plots sysimage:

and inside the repl run:

using PackageCompiler
create_sysimage([:Atom,:Juno], sysimage_path="sys_atom_plots.so", precompile_statements_file="extracompilestmts.jl")

then modify the atom startup in order to use this new sysimage
I think that in this way you should be able to also remove this overhead, this same procedure has given me a blazing fast Juno!

i used this trick not on a sysimage with Plots, but on a sysimage with DataFrames and CSV, and in this way i recovered the speed that this custom sysimage had on a terminal inside Atom.

i do not believe that this problem is a PackageCompiler problem...
let me know if it worked for you also

[greimel]

On Ubuntu I cannot reproduce that every call is slow, just the first one.

julia> @time using Plots
  0.000253 seconds (759 allocations: 40.609 KiB)

julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
  8.537356 seconds (14.40 M allocations: 727.738 MiB, 2.49% gc time)

julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
  0.215557 seconds (38.82 k allocations: 1.832 MiB)

julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
  0.210533 seconds (24.11 k allocations: 1.162 MiB)

Following the steps provided by @francescoalemanno (thanks!), the timings change to

Press Enter to start a new session.
Starting Julia...
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.4.0 (2020-03-21)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> ┌ Warning: Atom.jl: unrecognised message ismodule.
└ @ Atom ~/.julia/packages/Atom/X8fAI/src/comm.jl:171
julia> @time using Plots
  0.000256 seconds (577 allocations: 30.109 KiB)

julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
  0.591330 seconds (124.40 k allocations: 6.602 MiB)

julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
  0.198933 seconds (16.98 k allocations: 1.021 MiB)

julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
  0.210599 seconds (17.26 k allocations: 1.029 MiB)

Beware: when specifing the trace file in juno --trace-compile=path/to/file.jl, do not quote the path. This caused me some headache.

I also show the header to show that there is warning from Juno now. I hope that this doesn't cause any trouble.

[asinghvi17]

This may be because Juno loads specific versions of some dependencies, meaning that if Juno and Plots have a common dependency, Plots have some of the code it was relying on invalidated. Does the slowdown also happen when you compile the sysimage from within Atom?

[greimel]

yes

[terasakisatoshi]

I've created two gists that may resolve this issue based on @francescoalemanno 's comment

• Atom/Juno
  • https://gist.github.com/terasakisatoshi/0fe5777996598dd654df81ec9770c0e3
• IJulia
  • https://gist.github.com/terasakisatoshi/e9c2a674fee5e6b5d2a855192cd85ef3

[greimel]

Note that you actually omitted the key step that @francescoalemanno came up with.

go to Juno settings, search for the option to add julia startup arguments and add something like:

--trace-compile=/home/me/extracompilestmts.jl,--sysimage=mysysimage_withPlots.so

restart Atom, open the repl in atom and use generate some plots.
keep atom open and do not restart julia.

Go to your home directory and copy the file "extracompilestmts.jl" somewhere else, now you can close Atom.

You might actually get an even bigger speed-up with that. See my timings above (for Ubuntu).

[terasakisatoshi]

Ah ... yes I knew, you're right. Here is the result I adopt the below :

search for the option to add julia startup arguments and add something like:

--trace-compile=/home/me/extracompilestmts.jl,--sysimage=mysysimage_withPlots.so

julia> @time using Plots
  0.013477 seconds (351 allocations: 18.609 KiB)
julia> @time plot(cos) |> display 
Plot{Plots.GRBackend() n=1}
  0.465284 seconds (136.17 k allocations: 7.087 MiB, 6.41% gc time)

I admit the performance is better than my approach

Atom/Juno
https://gist.github.com/terasakisatoshi/0fe5777996598dd654df81ec9770c0e3

However, it requires manual operation (e.g. open Atom and add argument something) which is a bit annoying for me.

[KristofferC]

I don't think there is anything to do here from PackageCompiler's p.o.v. As shown in #352 (comment) it seems very possible to get a good Plots.jl first time even in Atom.