'using Plots' takes 20 seconds or more

As of 1.4, I get 6 seconds (after precompile), so not fully fixed yet but about 3x better. It’s still improving though. 1.4 is better than 1.3, and 1.5 will be better than 1.4 was.


really good news.

Gnuplot.jl (master branch, new release due in a few days) takes ~5 seconds with the default qt terminal, and no precompilation or modified system image:

but uses gnuplot as backend…


Just one more data point… Gaston master (precompiled):

$ time julia -e 'using Gaston; plot(randn(10^6),randn(10^6))'

real	0m1.000s
user	0m1.168s
sys	0m1.379s

I can confirm that both Gaston and Gnuplot are very capable. And FAST. I highly recommend this to anyone who is looking for fast plotting. Knowledge of gnuplot is a plus, of course, but for someone programming in Julia that shouldn’t be a problem.


Plots has good speed on the second plot as we all know, unlike the (slight) second-plot issue I discovered with another package:

There’s no real need to do this redundantly (might still happen in real-world code), but using only gets stable (allocations/speed) on third use (unlike for Gaston, where it only applies to the plot):

julia> @time using Plots
  9.869769 seconds (7.44 M allocations: 422.704 MiB, 2.78% gc time)

julia> @time using Plots
  1.492128 seconds (1.70 M allocations: 80.019 MiB, 1.90% gc time)

julia> @time using Plots
  0.000298 seconds (276 allocations: 14.859 KiB)
1 Like

Is this issue still actively worked on?

@time using Plots
11.354988 seconds (18.48 M allocations: 1.024 GiB, 3.34% gc time)

$ time julia -e “using Plots”

real 0m11,482s
user 0m10,651s
sys 0m0,373s

$ time python -c “import matplotlib”

real 0m0,868s
user 0m0,411s
sys 0m0,264s

$ time gnuplot -e “”

real 0m0,026s
user 0m0,023s
sys 0m0,003s

I thought Julia wanted to rival C’s speed, not be slower than python.

1 Like

What version are you on? On Master, I’m seeing 3 seconds, which while not solved, is a massive improvement. (time julia -e “using Gaston” also clocks in at just over 1 second for me)

1 Like

I’m using the latest version that Arch Linux ships: julia version 1.5.3

$ time julia -e “using Gaston”

real 0m1,743s
user 0m1,580s
sys 0m0,146s

In that case, you will see a very major improvement once 1.6 is released. A ton of work has gone into this in the past half year or so, an it remains one of the main developer priorities.


Ok, thank you.

This is a serious tip. Installed in <<1min, precompiled in <6s, plotted in <4s.

I do love what Plots.jl offers, but - for more routine poking around this may be my go to.


I want to point out, these aren’t strictly comparable. In julia, the latter is same as using PyPlot. It gives you MATLAB-compatible plotting, in fact, the exact same as matplotlib (as you use that through Python).

Yes, it’s still a bit slower to start up, while GR.jl’s is comparable to matplotlib:

$ time julia -O0 -e "using GR"

real	0m0,310s

It’s the default backend for Plots.jl, and you can use it alone, without the abstraction of Plots. It’s fast since it’s already compiled code (i.e. non-Julia code, yes, plus some minimal Julia wrapper code), in that sense comparable, and faster, than the Python situation:

I’m not sure what’s the go-to Python plotting abstraction library, or if there is one, and most people use that one option.

In theory the wrapper, Plots.jl, and all Julia-only code, could be fully compiled. Currently it’s (partially) precompiled.

1 Like

I know that the three examples are not exactly the same. I should have wrote: “using Plots” takes long compared to the startup times of common C or python libraries.

Do you mean matplotlib compatible?

Do you mean matplotlib compatible?

Yes, which is compatible with MATLAB.* See: https://github.com/JuliaPy/PyPlot.jl (and matplotlib’s docs):

In general, all of the arguments, including keyword arguments, are exactly the same as in Python. (With minor translations, of course, e.g. Julia uses true and nothing instead of Python’s True and None .)

The full matplotlib.pyplot API is far too extensive to describe here; see the matplotlib.pyplot documentation for more information.

To clarify, Python’s matplotlib is a moving target. I just know what the documentation says. It seems to be a full wrapper, but let’s say something gets added to the Python side, then I’m not sure how PyPlot keep up (for new interfaces that is, bugfixes that do not change the interface likely just get upgraded).

* I did write MATLAB-compatible on purpose, meaning matplotlib (and thus PyPlot indirectly) a (supposed) clone, i.e. both compatible with MATLAB’s plotting.

I wouldn’t use the word “compatible” for PyCall in relation to matplotlib, implying trying to be, when it should be identical, using the same code.

I guess MATLAB’s plotting is also a moving target, and while PyPlot.jl is hopefully compatible with it, it’s to the same degree as Python’s matplotlib, no more. I.e. it’s supposedly compatible, or do I just assume?

I did try to look up matplotlib’s docs and I can’t find MATLAB mentioned, maybe for trademark reasons.

I’ve ported code from MATLAB to Julia, including plotting code, and the interface seemed similar, I had to skip some, e.g. “hold on” that I didn’t immediately see how to do (it’s neither legal syntax in Julia nor Python, maybe I just overlooked how to do this).

You can even use the MATLAB engine, call using MATLAB.jl, to call code for computation (I didn’t try to get it to plot, I do not think appropriate for that, I might be wrong, unlike you can do by calling Python).

Let’s say PyPlots’s wrapper gets outdated, you could use matplotlib directly through PyCall.jl. PyPlot uses it, just to make the interface like native Julia, but it’s not at all hard to use any Python code directly.

Upgrading to Julia 1.5.3 :

julia> @time using Plots
@time plot(rand  8.158916 seconds (10.53 M allocations: 651.018 MiB, 2.86% gc time)

julia> @time plot(randn(20))
  2.671723 seconds (4.52 M allocations: 235.500 MiB, 2.44% gc time)

This is a huge improvement to what I was getting before and is tolerable. Excited to see 1.6!

To answer my own question here, it seems like matplotlib is it!

PyPlot has GR.jl as default backend, and matplotlib optional, but matplotlib also has backends, and gr is one of it. And mplcairo is another. I didn’t look into what’s their default, maybe it’s gr, so it’s just about the API.

[Note, there seems also to be a GUI backend to it, I found code to query and change it.]

1 Like
julia> @time using Plots
  4.004548 seconds (6.43 M allocations: 468.557 MiB, 5.07% gc time, 21.25% compilation time)

julia> @time plot(randn(20))
  3.104825 seconds (3.29 M allocations: 201.521 MiB, 7.70% gc time, 99.69% compilation time)

julia> VERSION

Note that this is a not-so-powerful laptop.


I see this on my Macbook Pro

julia> @time using Plots
  2.814411 seconds (5.89 M allocations: 422.216 MiB, 5.13% gc time, 19.86% compilation time)

julia> @time plot(randn(20))
  2.296894 seconds (3.50 M allocations: 208.185 MiB, 11.26% gc time, 99.48% compilation time)

julia> VERSION

This plus Revise essentially solves the plotting problem for me. v1.6 is simply amazing.


Unfortunately that is not always true. With GMT I see a regression.

julia> @time using GMT
  0.998829 seconds (1.10 M allocations: 65.532 MiB, 1.60% gc time)

julia> @time plot([0.0 0; 1.1 1])
  3.602529 seconds (1.02 M allocations: 53.377 MiB, 0.45% gc time)

julia> VERSION


julia> @time using GMT
  1.111520 seconds (1.43 M allocations: 89.916 MiB, 2.97% gc time, 54.24% compilation time)

julia> @time plot([0.0 0; 1.1 1])
  4.578288 seconds (3.74 M allocations: 174.832 MiB, 2.10% gc time, 99.43% compilation time)

julia> VERSION
1 Like