gr backend - savefig extremely slow (~2.5s per .png on 9950X and i9-12950HX)

[wCTcTU4P]

I noticed this when running some data analysis programs at work - the automated (default gr backend) plots I have in those programs were taking extremely long, probably 10-20x vs. prior runs.

It had been awhile since I ran some of these, but this was never the case before. The plots are simple and saved as png's almost instantly, whereas they are now about 2.5s each.

This is on Windows 11 enterprise, Julia 1.11.4, Plots 1.40.19 at work, on an i9-12950HX CPU.

I also ran it on my desktop (Windows 11 pro), on an AMD 9950X CPU, on both Julia 1.11.4 and 1.11.6 (Plots 1.40.19 on both), and the results are the same.

The plots are a bit deep in the programs I have, and they make dozens of plots in some cases; however, the issue can be replicated with a line as simple as:

julia> @timev savefig(plot(rand(1500)),"test.png")
  2.646581 seconds (43.80 k allocations: 1.122 MiB)

julia> @timev savefig(histogram(rand(1500)),"test.png")
  2.575007 seconds (11.23 k allocations: 569.711 KiB)

These results correspond to my mass-plotting results for the data analysis programs I run at work. Not sure what changed or when exactly, but last I used my automated programs before this issue (maybe a couple months ago?), there was no issue like this. I've been mass-plotting and saving like this for several years and never had this issue.

Backends

This bug occurs on ( insert x below )

Backend	yes	no	untested
gr (default)	x
unicodeplots			x
pythonplot			x
pgfplotsx			x
plotlyjs			x
plotly			x
gaston			x

Versions

Plots.jl version: [91a5bcdd] Plots v1.40.19

julia> versioninfo()
Julia Version 1.11.6
Commit 9615af0f26 (2025-07-09 12:58 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: 32 × AMD Ryzen 9 9950X 16-Core Processor
WORD_SIZE: 64
LLVM: libLLVM-16.0.6 (ORCJIT, generic)
Threads: 32 default, 0 interactive, 16 GC (on 32 virtual cores)
Environment:
JULIA_EDITOR = code
JULIA_VSCODE_REPL = 1

[t-bltg]

It would be helpful to see if this performance regression comes from Plots or GR itself.

Can you do benchmark something similar to @timev savefig(plot(rand(1500)),"test.png") in plain GR i.e. by not using Plots ?

[wCTcTU4P]

looks like I get this when the figure is not currently onscreen for GR.jl

julia> @Timev plot(rand(1500)); savefig("test.png")
2.548841 seconds (475 allocations: 41.779 KiB)
elapsed time (ns): 2.5488411e9
gc time (ns): 0
bytes allocated: 42782
pool allocs: 473
non-pool GC allocs: 0
malloc() calls: 2
free() calls: 0
minor collections: 0
full collections: 0

I've submitted jheinen/GR.jl#571 for GR.jl, since this issue seems to originate there. Thanks for your help!

[wCTcTU4P]

Okay, somewhat of an update here - while Savefig is also slow on the first run in GR.jl, GR moves fast on consecutive runs, while Plots.jl is slow on all savefig calls. Basically the 2-3 window opening latency happens once in GR.jl, but every savefig call in Plots.jl.

I gave more details here: jheinen/GR.jl#571 (comment)

I'm not sure where in the interface between GR.jl and Plots.jl this occurs, but it seems like a plausible root cause and may actually be in Plots.jl.