| | |_| | | | (_| | | Version 1.9.0 (2023-05-07)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> @time_imports using GMT
0.6 ms Statistics
0.2 ms DataValueInterfaces
0.7 ms DataAPI
0.2 ms IteratorInterfaceExtensions
0.2 ms TableTraits
17.7 ms Tables
0.5 ms Formatting
0.2 ms Reexport
19.2 ms StringManipulation
12.2 ms Crayons
0.4 ms LaTeXStrings
55.3 ms PrettyTables
7.3 ms Preferences
0.2 ms PrecompileTools
1092.0 ms GMT
julia> @time @eval plot([0. 0.; 1. 1])
2.809241 seconds (9.58 M allocations: 605.994 MiB, 6.80% gc time, 99.61% compilation time: 94% of which was recompilation)
| | |_| | | | (_| | | Version 1.10.0-DEV.1510 (2023-06-19)
_/ |\__'_|_|_|\__'_| | Commit 690a5f67c1 (2 days old master)
|__/ |
julia> @time_imports using GMT
┌ 5.3 ms SparseArrays.CHOLMOD.__init__() 80.90% compilation time
303.4 ms SparseArrays 9.25% compilation time
0.7 ms Statistics
0.2 ms DataValueInterfaces
0.8 ms DataAPI
0.3 ms IteratorInterfaceExtensions
0.2 ms TableTraits
5.7 ms Tables
0.5 ms Formatting
0.2 ms Reexport
8.9 ms StringManipulation
8.2 ms Crayons
0.5 ms LaTeXStrings
31.8 ms PrettyTables
5.8 ms Preferences
0.3 ms PrecompileTools
┌ 15.4 ms GMT.Gdal.__init__()
├ 12.6 ms GMT.__init__()
655.9 ms GMT
julia> @time @eval plot([0. 0.; 1. 1])
0.558401 seconds (1.25 M allocations: 85.007 MiB, 2.38% gc time, 98.82% compilation time: 58% of which was recompilation)
The new command line option --heap-size-hint in v1.9 makes it much easier for me to run jobs on shared clusters without running out of memory. You can tell the GC how much RAM you actually requested from the cluster’s queue system, rather than the total memory of the nodes running the job.
Yes, I’m on Windows. But my timings are for GMT.jl plot, not Plots plot. And also mind you that @time alone, at least for my case, does not report the true time. e.g. in 1.9
julia> @time plot([0. 0.; 1. 1])
1.015570 seconds (3.47 M allocations: 212.676 MiB, 7.15% gc time, 99.74% compilation time: 87% of which was recompilation)
Mostly just a bunch of profiling and fixing the expensive parts. see Pull requests · JuliaLang/julia · GitHub for a list of a decent chunk of them. (omnipackage was a package made for benchmarking loading issues that just includes a couple thousand packages including the DIffEq stack, ML stack, Plots, and a few other things)
Package improvements would probably impact both 1.9 and 1.10 (but might not improve 1.8, e.g. switching to PkgExtensions, caching more in the package image).