GLMakie is too slow for use in scripting

[bc0n]

I really want to use Julia but something's very wrong with GLMakie, 63 seconds to plot a 20-point sine wave. What's broken?
Julia 1.6.0, GLMakie v0.2.4, (see package status below).

My workflow is script-based, so <plotting.jl> has

using GLMakie
function test()
    x = LinRange(0, 10, 100)
    Scene()
    fig, ax, sco = scatter(x, sin.(x), color = :red, markersize = 5)
    display(fig)
end
@time test()

julia plotting.jl
63.648772 seconds (106.13 M allocations: 6.270 GiB, 3.34% gc time, 31.71% compilation time)
on a Ryzen 5 1600x six core desktop with 32 gb ram and a gtx 1050i under Linux Min 19 Cinnamon 3.8.9.
glxinfo says: OpenGL version string: 4.6.0 NVIDIA 450.119.03

Adding GLMakie.WINDOW_CONFIG.vsync[] = false from #267 yields no improvement. Running the same function through a Jupyter notebook with CairoMakie takes 0.035412 seconds (55.30 k allocations: 3.962 MiB).

Is this a known limitation or what can I do to help you look into and fix it?

pkg status:

     Status `~/.julia/environments/v1.6/Project.toml`
  [13f3f980] CairoMakie v0.4.2
  [5ae59095] Colors v0.12.6
  [1fa38f19] Format v1.3.0
  [e9467ef8] GLMakie v0.2.4
  [c91e804a] Gadfly v1.3.2
  [5c1252a2] GeometryBasics v0.3.12
  [7073ff75] IJulia v1.23.2
  [2b0e0bc5] LanguageServer v3.2.0
  [438e738f] PyCall v1.92.3
  [cf896787] SymbolServer v5.1.1
  [0c5d862f] Symbolics v0.1.11
  [1986cc42] Unitful v1.6.0
  [ddb6d928] YAML v0.4.6
  [de0858da] Printf
  [9abbd945] Profile

Running the same in vsCode (debug) trips over an error in functionloading.jl line 68,

TypeError: in typeassert, expected Type, got a value of type Ptr{Nothing}
Stacktrace:
  [1] glGenFramebuffers(n::Int64, framebuffers::Vector{UInt32})
    @ ModernGL ~/.julia/packages/ModernGL/rVuW2/src/functionloading.jl:68
  [2] glGenFramebuffers()
    @ GLMakie.GLAbstraction ~/.julia/packages/GLMakie/Iybut/src/GLAbstraction/GLExtendedFunctions.jl:139
  [3] GLMakie.GLFramebuffer(fb_size::Tuple{Int64, Int64})
    @ GLMakie ~/.julia/packages/GLMakie/Iybut/src/glwindow.jl:30
  [4] GLMakie.Screen(; resolution::Tuple{Int64, Int64}, visible::Bool, title::String, kw_args::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ GLMakie ~/.julia/packages/GLMakie/Iybut/src/screen.jl:343
  [5] GLMakie.Screen()
    @ GLMakie ~/.julia/packages/GLMakie/Iybut/src/screen.jl:289
  [6] global_gl_screen()
    @ GLMakie ~/.julia/packages/GLMakie/Iybut/src/screen.jl:235
  [7] global_gl_screen(resolution::Tuple{Int64, Int64}, visibility::Bool, tries::Int64)
    @ GLMakie ~/.julia/packages/GLMakie/Iybut/src/screen.jl:382
  [8] global_gl_screen(resolution::Tuple{Int64, Int64}, visibility::Bool)
    @ GLMakie ~/.julia/packages/GLMakie/Iybut/src/screen.jl:381
  [9] backend_display(#unused#::GLMakie.GLBackend, scene::Scene)
    @ GLMakie ~/.julia/packages/GLMakie/Iybut/src/display.jl:2
 [10] display(scene::Scene)
    @ AbstractPlotting ~/.julia/packages/AbstractPlotting/Dnsku/src/display.jl:61
 [11] display(fig::Figure)
    @ AbstractPlotting ~/.julia/packages/AbstractPlotting/Dnsku/src/display.jl:51
 [12] test()
    @ Main ~/sync/reference/julia/plotting.jl:12
 [13] top-level scope
    @ timing.jl:210

[jkrumbiegel]

If you run a script with a fresh julia session each time this is expected. If you run it multiple times in the same session the speed should be comparable to CairoMakie.

[SimonDanisch]

We're in the middle of improving compile times, but it will still take some time to significantly improve compile tmes for Makie, since we'll need to improve the compilation of quite a few dependencies and the core Makie code ...

Running the same in vsCode (debug) trips over an error in functionloading.jl line 68

I've never seen that error... Can you open a separate issue with concise steps on how to reproduce it, with OS, Julia and ModernGL.jl versions?

[bc0n]

Thanks @SimonDanisch @jkrumbiegel. Does anyone have a vsCode launch.json that keeps the julia session open? The default always opens a new terminal, forgetting the compilation.

If other newbs happen by a sufficient solution is

julia> include("plotting.jl")
 64.912922 seconds (106.12 M allocations: 6.270 GiB, 3.37% gc time, 30.72% compilation time)
  0.055796 seconds (82.39 k allocations: 7.129 MiB, 15.51% compilation time)
  0.053360 seconds (72.96 k allocations: 6.595 MiB)
  0.050897 seconds (72.96 k allocations: 6.587 MiB)
  0.051245 seconds (72.96 k allocations: 6.587 MiB)
GLMakie.Screen(...)

julia> include("plotting.jl")
  0.243971 seconds (95.92 k allocations: 11.582 MiB, 11.01% compilation time)
  0.051730 seconds (72.96 k allocations: 6.587 MiB)
  0.046984 seconds (72.96 k allocations: 6.595 MiB)
  0.046390 seconds (72.96 k allocations: 6.587 MiB)
  0.045736 seconds (72.96 k allocations: 6.587 MiB)
GLMakie.Screen(...)

(where @time test was copy-pasted 5 times.)

[SimonDanisch]

Does anyone have a vsCode launch.json that keeps the julia session open?

I'm not sure what you mean exactly... But the Julia vscode plugin has pretty amazing support for evaluating Julia code in scripts, modules, packages etc, while keeping the julia process running:
https://www.julia-vscode.org/