Banded matrix support triples compile time #954
Comments
|
This seems to be caused primarily by SparseDiffTools. |
|
Looks like the issue is BandedMatrices.jl: @time using BandedMatrices # 14.922930 seconds (33.07 M allocations: 2.179 GiB, 5.20% gc time)
@time using BlockBandedMatrices # 6.882466 seconds (5.43 M allocations: 339.653 MiB, 3.98% gc time)
@time using DiffEqDiffTools # 1.188521 seconds (729.68 k allocations: 37.182 MiB, 8.63% gc time)
@time using ForwardDiff # 0.918514 seconds (749.80 k allocations: 46.918 MiB, 3.23% gc time)
@time using LightGraphs # 0.827393 seconds (479.37 k allocations: 25.458 MiB, 1.46% gc time)
@time using Requires # 0.001731 seconds (757 allocations: 40.563 KiB)
@time using VertexSafeGraphs # 0.035792 seconds (27.22 k allocations: 1.399 MiB)
@time using Adapt # 0.076683 seconds (24.38 k allocations: 1.382 MiB)
@time using LinearAlgebra # 0.004319 seconds (1.60 k allocations: 88.016 KiB)
@time using SparseArrays # 0.003787 seconds (1.61 k allocations: 88.203 KiB)
@time using ArrayInterface # 0.210675 seconds (96.83 k allocations: 5.000 MiB) |
ChrisRackauckas
changed the title
|
I’m in the process of simplifying BandedMatrices which should hopefully fix this |
|
Good to hear. I would hate to drop the automated banded matrix support due to this, since banded matrices are quite common! In fact, I was hoping to add an example using a BandedMatrix as the Jacobian type in http://docs.juliadiffeq.org/latest/tutorials/advanced_ode_example.html#Using-Structured-Matrix-Types-1 , so this will be getting more and more ingrained into what we are doing. |
|
Unfortunately my "grand scheme" to improve loading time is not as successful as I thought: julia> @time using BandedMatrices
5.957725 seconds (31.10 M allocations: 2.030 GiB, 7.27% gc time)This is in branch JuliaLinearAlgebra/BandedMatrices.jl#146 That removes all LazyArray code. I'll have to do code-bisection to see if I can track down the culprit: though it may just be |
|
Honestly it should be added to Base to be in the sysimage and allow more of LinearAlgebra to produce and use BandedMatrix outputs, but that's a whole different story. |
|
First step is getting https://github.com/JuliaMatrices/ArrayLayouts.jl into StdLib/LinearAlgebra.jl. This implements a trait-based version of This will avoid the need for |
|
I think the culprit is actually MatrixFactorizations.jl, which is almost verbatim the same as StdLib/LinearAlgebra.jl code (it adds a Probably I can get rid of a lot of the |
|
Hmm, Even taking out MatrixFactorizations only reduces it to 4s. Looking at Code-bisection it's completely due to The only reasonable way to improve this is to rewrite StdLib/LinearAlgebra.jl to not use |
|
Actually, JuliaDiff/SparseDiffTools.jl@71693f9 it's all handed by ArrayInterface.jl, so we don't need it. |
|
JuliaDiff/SparseDiffTools.jl@eb42179 Thanks @jebej for the hunting. Everything is handled through Requires, so all Banded stuff is opt-in. I hope this gets fixed, but at least it's not an issue that's going to be apparent unless someone specifically asks for banded now! |
|
I have an idea on how to work around this: just loop over concrete types that make up |
|
It appeard OrdinaryDiffEq is slow again, taking 10s to load. |
|
Can you help figure out what dependency it is? My guess is that it's Zygote. |
|
It appears the issue is mostly DiffEqBase, in combination with ForwardDiff & FiniteDiff. I don't think Zygote is loaded by OrdinaryDiffEq. |
|
Zygote is loaded in DiffEqBase. ForwardDiff |
|
On their own: |
|
Should I make a new issue here? |
|
yes |
On my fast desktop, running
@time using OrdinaryDiffEqtakes 15 seconds.A couple of versions ago, it used to start much more quickly. I manually checked the loading time in a clean environment, and the biggest jump in load time happens when moving from 5.11.1 to 5.12.0.
The time goes from ~5sec to 15sec. Hopefully this can be improved.
The text was updated successfully, but these errors were encountered: