Large load time

[MilesCranmer]

Trying to make SymbolicRegression.jl have a faster startup time. On 1.11.6 it seems SparseArrays.jl accounts for a decent chunk of the load time. Here's the breakdown of the biggest contributors (launched from REPL) -

Package	Time (ms)	Notes
Pkg	180.1	0.0 ms init
SparseArrays	116.5	Includes SuiteSparse_jll (18.8 ms), CHOLMOD init (6.1 ms), 3.42% compilation
Pkg → REPLExt	81.4	0.4 ms init
DynamicQuantities	61.1
Distributed	57.9	0.0 ms init, 88.13% compilation
DynamicExpressions	38.1
FillArrays	26.7
ForwardDiff	18.8
Downloads	17.4	4.0 ms Curl init
CompilerSupportLibraries_jll	16.3	12.8 ms init
DataStructures	13.0
Dates	12.7	484.73% compilation

julia> @time_imports using SparseArrays
               ┌ 12.7 ms SuiteSparse_jll.__init__()
     98.4 ms  SuiteSparse_jll 83.64% compilation time
      1.4 ms  Serialization
               ┌ 5.8 ms SparseArrays.CHOLMOD.__init__() 73.45% compilation time
     96.0 ms  SparseArrays 4.45% compilation time

[ViralBShah]

I was wondering if this is because it isn't in the system image - but presumably many other things are also not in the system image.

I guess the package is also pretty large at 18,000 LOC.

[ViralBShah]

@KristofferC Any tricks we can do here?

[KristofferC]

Nothing directly other than speeding up package loading in general (assuming SparseArrays.jl doesn't do something "pathological" that heavily penalizes it's load time).

[JamesWrigley]

By the advanced technique of commenting stuff out I found that:

• linalg.jl is ~13% of the total code but it takes up just over half the load time, which on Julia 1.13 on my machine is ~200ms.
• These kron() methods alone take ~35ms of the load time:

  SparseArrays.jl/src/linalg.jl

  Lines 1934 to 1938 in 3ab784c

  	kron(A::_SparseKronGroup, B::_SparseKronGroup) =
  	kron(convert(SparseMatrixCSC, A), convert(SparseMatrixCSC, B))
  	kron(A::_SparseKronGroup, B::_DenseKronGroup) = kron(A, sparse(B))
  	kron(A::_DenseKronGroup, B::_SparseKronGroup) = kron(sparse(A), B)
  	kron(A::_SparseVectorUnion, B::_AdjOrTransSparseVectorUnion) = A .* B

  
  Presumably because they accept big unions.

[KristofferC]

Extending the LinearAlgebra methods is indeed very expensive due to the complicated type signatures. CUDA has the same issue.