Did a quick test of 1.8-beta3 in comparison to 1.7.2. Results: Package load time (@time using KiteModels): Julia 1.7.2 3.3 s Julia 1.8 beta 3.8 s Execution time of the function loop(): Julia 1.7.2 910 ns Julia 1.8 beta 993 ns Hopefully that will still improve until the final release.

I’ve also experienced quite a bit of compilation slowdown with v1.8. A package I was working on improving compile times for went from 10 minutes to run the complete test suite to over 12 minutes, in both cases precompilation was done before timing. It’s possible that more can be done to cache precom…

It would help to distinguish a few timing benchmark types: pre-compilation time (what happens usually only when you run an update of a package) loading time, e.g. @time @eval using MyLibrary time to first X, a.k.a. TTFX, e.g. @time @eval (using MyLibrary; MyLibrary.typical_task()) Loading time …

I would actually expect that PR to make package loading slower, since it saves more things in precompile files and therefore has to load more. But it should cut down compilation time, giving a net improvement. However in this case there could be further compilation slowdowns preventing us from seein…

This one seems to be simply due to Plots.jl not having precompiles for 1.8: https://github.com/JuliaPlots/Plots.jl/pull/4179

Nope, the plot from my post is the GMT.jl plot, not the one from Plots.jl

Oops, my mistake, I should have noticed that. Time to get profiling…

I would actually expect that PR to make package loading slower, since it saves more things in precompile files and therefore has to load more. That is true, but profiling shows that the slowest part of package loading is not the I/O but method and backedge insertion. Backedges can be pre-calculat…

KiteModels is using InlineStrings which is invalidating Base.require. Which means that loading InlineStrings makes it necessary to recompile the package-loading machinery before the next dependency of KiteModels can be loaded. Ugh. This has been fixed, presumably, on nightly ( https://github.com/Jul…

Likewise, GMT.plot is getting invalidated (so the precompilation isn’t working): julia> print_tree(root, 20) MethodInstance for SnoopCompile.dummy() at depth 0 with 17 children └─ MethodInstance for copyto!(::BitMatrix, ::Broadcasted{Nothing, Tuple{OneTo{Int64}, OneTo{Int64}}, typeof(==), Tuple{Ref…

Thanks, I made the change (actually two of them) you suggested and it cut down ~1 sec but it’s still ~2 sec slower than 1.7 julia> tic(); plot(rand(5,2)); toc() elapsed time: 8.6452718 seconds 8.6452718 Maybe there are more of them.

Package load time regressions in v1.8-beta3

Internals & Design

stevengj Split this topic April 18, 2022, 11:39am 16

A post was merged into an existing topic: Printing of unsigned numbers

Topic		Replies	Views
Invalidations findings (from a GMT case) General Usage performance	64	2172	January 12, 2023
Potential performance regressions in Julia 1.8 for special un-precompiled type dispatches and how to fix them Performance performance	25	3597	October 4, 2022
Help building MWE for 1.8 latency regression Performance	11	1021	November 2, 2022
Mystery of invalidations in V>1.10. Even in precompiled code General Usage regression , method-invalidation , ttfp , ttfx	10	442	September 7, 2025
Large performance regression in nightly build Performance	6	794	February 25, 2022

Package load time regressions in v1.8-beta3

Related topics